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System, Method, and Computer Program Product for 
Managing and Analyzing Intellectual Property (IP) Related 

Transactions 

Background of the Invention 
Field of the Invention 

The present invention is generally related to tools for data processing, and 
more particularly related to tools for patent-centric and group-oriented data 
processing. The tools include modules to track and process IP related 
transactions, such as license agreements. 

Related Art 

Patents are becoming more and more important to a business's success, 
especially in today's global economy. Patents can be viewed as a new type of 
currency in this global economy because they grant the holder with a right to 
exclude others from making, using, or selling the patented technology. In some 
industries^ product turnover is fairly rapid. However, core technology, product 
features, and markets change at a much slower rate. Accordingly, even in fast- 
moving industries, patents which cover core technology are very valuable at 
protecting a company's research and development investment for an extended 
period of time. 

Patents are also valuable as revenue generators. In 1993, for example, the 
revenue generated from patents by U.S. companies was over $60 billion. Fred 
Warshofsky, The Patent Wars, John Wiley & Sons, Inc., New York, 1994. These 
patent revenue dollars are rising each year. 

Patents are further valuable because they collectively represent a vast 
technological database. Much of this database is only available as issued patents 
(i.e., it is not released in any other form). According to Larry Kahaner's book, 
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Competitive Intelligence, Simon & Schuster, 1996, "More than 75 percent of the 
information contained in U.S. patents is never released anywhere else." 

More and more corporations are recognizing the value of patents. The 
number of patents applied for and issued to U.S. companies is increasing every 
year, especially in fast moving industries such as computer software and 
biotechnology. Many international companies have also recognized the value of 
patents. In fact, foreign companies regularly rank among the leaders in issued 
U.S. patents. 

Yet, for all the heightened awareness being paid to patents in some 
quarters, patents remain one of the most underutilized assets in a company's 
portfolio. This is due, at least in significant part, to the fact that patent analysis, 
whether for purposes of licensing, infringement, enforcement, freedom to operate, 
technical research, product development, etc., is a very difficult, tedious, time 
consuming, and expensive task, particularly when performed with paper copies 
of patents. 

Software providers have been slow in developing software tools for aiding 
in the patent analysis process. As a result, there are few automated tools for 
patent analysis currently available. There are software tools available for 
managing corporate patent prosecution and payment of maintenance fees, such 
as products from Master Data Corporation. The patent analysis capabilities of 
these tools are limited. These tools, for example, cannot be used to facilitate the 
analysis and development of business strategies to increase corporate shareholder 
value through the strategic and tactical use of patents. 

A number of patent searching tools are available, such as the United 
States Patent and Trademark Office (USPTO) Automated Patent System (APS), 
and the on-line search services offered by Lexis and Westlaw. Other providers 
of patent information and patent search tools include Derwent, MicroPatent, 
Questel. Corporate Intelligence, STN, IFl/Plenum, The Shadow Patent Office 
(EDS), IBM, and CAS. These tools are not analysis tools. Instead, they are search 



wo 00/11575 



-3- 



PCT/US99/19050 



tools. These tools enable a user to identify patents that satisfy a specified key 
word search criteria. In essence, these tools provide the user with the ability to 
possibly find "the needle-in-the-haystack." However, these tools have limited, if 
any, automated functions to aid a user in analyzing the patents, whether the 
company's own patents or those of competitors, for the purpose of making tactical 
and strategic business decisions based on the patents. 

SmartPatents Inc. (SPI) of Mountain View, CA, provides electronic tools 
for analyzing patents. These tools, collectively called the SmartPatent 
Workbench, are very useful for analyzing patents. With the SmartPatent 
Workbench, a user can view the text and image of a patent, conduct text searches 
in the patent, copy and paste portions of the patent to other documents, build a 
case of patents, annotate the case and the patents in the case, import and export 
patents and cases, etc. The SmartPatent Workbench is commercially available 
from SPI, and is described in a number of publicly available documents, such as 
U.S. Patent No. 5,623,679 and U.S. Patent No. 5,623,681. 

For the most part, existing patent-related tools can process only the 
information contained in patents. (It is noted, however, that the SmartPatent 
Workbench has functions to annotate patents with any information, whether or 
not patent related, and has additional functions to search within annotations.) 
These tools do not have functions for correlating, analyzing, and otherwise 
processing patent-related information with non-patent related information, 
including but not limited to corporate operational data, financial information, 
production information, human resources information, and other types of 
corporate information. Such non-patent information is critically important when 
evaluating the full strategic and tactical value and applicability of any given 
patent, or developing a corporate patent business strategy for gaining competitive 
advantage and increasing shareholder value based on patents. 
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Summary of the Invention 

Briefly stated, the present invention includes a system, method, and 
computer program product to track, analyze, and report on information related to 
intellectual property (IP) transactions, including license and related agreements. 

Further features and advantages of the invention, as well as the structure 
and operation of various embodiments of the invention, are described in detail 
below with reference to the accompanying drawings. In the drawings, like 
reference numbers generally indicate identical, functionally similar, and/or 
structurally similar elements. The drawing in which an element first appears is 
indicated by the leftmost digit(s) in the corresponding reference number. 

Brief Description of the Figures 

The present invention will be described with reference to the 
accompanying drawings, wherein: 

FIG. 1 illustrates the document-centric and patent-centric operation of the 
present invention; 

FIG. 2 is a block diagram of a system according to a preferred 
embodiment of the present invention; 

FIG. 3 is a block diagram of an enterprise server according to a preferred 
embodiment of the present invention; 

FIG, 4 is a block diagram of the databases of the present invention; 

FIG. 5 is a block diagram of a network client (and potentially a web 
client) according to an embodiment of the invention; 

FIG. 6 is a block diagram of the analysis modules which form a part of the 
enterprise server of FIG. 3; 
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FIG. 7 is a block diagram of a computer useful for implementing 
components of the invention; 

FIG. 8A illustrates the orientation of FIGS. 8B-8M relative to one 
another; 

FIGS. 8B-8M illustrates the tables and attributes in the databases of FIG. 
4 according to an embodiment of the invention; 

FIG. 9 represents an example console screen shot; 

FIG. 10 is another example console screen shot; 

FIG. 1 1 A illustrates a block diagram of a licensing module; 

FIG. IIB illustrates a more detailed block diagram of the licensing 
module according to an embodiment of the invention; 

FIG. 12 illustrates a standalone configuration of the licensing module; 

FIG. 13 illustrates an integrated configuration of the licensing module; 

FIG. 14 illustrates an example screen shot of an object display window 
generated by a licensing module according to an embodiment of the present 
invention; 

FIG. 15 illustrates an actor hierarchy according to an embodiment of the 
licensing module; 

FIG. 16 is a conceptional diagram of databases used by the licensing 
module according to an embodiment of the present invention; 

FIG. 17A is a block diagram of the functional modules in the licensing 
module according to an embodiment of the invention; 

FIG. 17B is a block diagram of a licensing administration module 
according to an embodiment of the invention; 

FIGS. 18. 20, 21, 23-29. 31, 36, 41. 45, 46, 48, 49, 58, 60-63, 73-80, 82- 
86, 87B, 91-94, 100-107, 109, and 118-124 are diagrams of use cases 
representing operational functions of the licensing module according to an 
embodiment of the invention; 
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FIG. 19 is an example screen shot of a log-in window according to an 
embodiment of the invention; 

FIG. 22 illustrates an example screen shot of a contact view according to 
an embodiment of the invention; 
5 FIG. 30 illustrates an example screen shot of an asset view according to 

an embodiment of the invention; 

FIG. 32 illustrates the use of pull down menus to create new objects 
according to an embodiment of the invention; 

FIGS. 33-35 illustrate example screen shots of dialogs for entering new 
10 patent assets according to an embodiment of the invention; 

FIGS. 37-40 illustrate example screen shots of dialogs for entering new 
trademark assets according to an embodiment of the invention; 

FIGS. 42-44 illustrate example screen shots of dialogs related to entering 
new copyright assets; 

15 FIG. 47 illustrates an example screen shot for entering a new know how 

asset according to an embodiment of the invention; 

FIGS. 50-57 and 59 illustrate example screen shots of dialogs and 
windows associated with asset packages; 

FIGS. 64A, 64B, 65, and 66 illustrate example screen shots of dialogs 
20 related to a find asset tool; 

FIG. 67 illustrates the manner in which a pull down menu can be used to 
invoke a find tool; 

FIGS. 68-72 and 81 illustrate example screen shots related to license 
agreements according to an embodiment of the invention; 
25 FIGS. 87 A and 88-90 illustrate example screen shots related to royalty 

statements according to an embodiment of the invention; 

FIGS. 95-99 illustrate example screen shots related to payments according 
to an embodiment of the invention; 
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FIG. 108 illustrates an example screen shot of a reports view according 
to an embodiment of the invention; 

FIGS. IIOA-IIOC, lllA-lllD, 112A-1I2F, 113, 114A-114B, 115A- 
1 1 5C, 116, and 1 17 illustrate example reports generated by the licensing module 
5 according to an embodiment of the invention; 

FIGS. 125 A and 125B illustrate a flowchart representing an example 
operational thread of an embodiment of the invention; 

FIGS. 126-150 illustrate block diagrams of subsystems of the licensing 
module according to embodiments of the invention; and 
10 FIGS. 151-163 illustrate additional use case diagrams representing 

additional functions supported by the present invention. 

In the following text, reference is sometimes made to existing U.S. 
patents. Also, some of the figures reference or illustrate existing U.S. patents. 
For illustrative purposes, information from and/or about these patents has 
15 sometimes been modified or created in order to support the particular examples 

being discussed. Accordingly, the information provided herein about these 
existing U.S. patents should be considered to be fictional unless verified through 
comparison with copies of the actual U.S. patents that are available from the U.S. 
Patent and Trademark Office. 

20 Detailed Description of the Preferred Embodiments 

Overview of the Invention 

The present invention is directed to a system, components of the system, 
a method, components of the method, and a computer program product for 
patent-centric and group-oriented data processing. Such processing includes, but 
25 is not limited to, reporting, analyzing, and planning. 
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FIG. 1 is a conceptual representation of the invention. The present 
invention processes patent information 104, which is herein defined to include 
(but not limited to) U.S. and non-U.S. patents (text and/or images) and post 
issuance documents (such as Certificates of Correction), and patent-related 
information, which includes information about patents (herein called patent 
bibliographic information). Accordingly, the processing performed by the 
invention is said to be "patent-centric" or "patent-specific." 

More generally, the present invention processes any documents, some of 
which are related to patents, and others which are unrelated to patents. These 
documents are preferably of interest to a business entity, and include contracts, 
licenses, leases, notes, commercial papers, other legal and/or financial papers, 
etc., as well as patents. 

For illustrative purposes, the invention is often described herein with 
respect to patents. However, it should be understood that the invention is also 
applicable to all types of documents, and the structures, functions, and operations 
described herein are applicable to all types of documents, whether patent or non- 
patent. 

The present invention also processes other information, preferably 
business-related information, including (but not limited to) research and 
development (R&D) information 106, financial information 1 1 6, patent licensing 
information 1 14, manufacturing information 108, and other relevant business 
information 1 1 0 (which may, for example, include human resources information). 
This other information is generally called non-patent information (since it 
includes documents other than patents and may further include information from 
operational and non-operational corporate databases). 

The present invention is adapted to maintain and process massive amounts 
of documents (several hundred thousand or more). It is often necessary to 
maintain and process this large number of documents in order to develop 
strategic, patent-related business plans for the customer. 
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According to the present invention, processing of the patent information 
104 can be conducted either with or without consideration of any of the other 
information 106, 116, 114, 110, 108. 

The present invention is group enabled. According to the present 
invention, a group is a data structure that includes a collection of patents. The 
patents in a group typically follow a common theme or characteristic (although 
this is not a mandatory requirement of groups). For example, a first group may 
include patents that map to a product being manufactured and sold by a company. 
A second group may include patents that map to a product or product feature 
being considered for future manufacture and sale by a company. A third group 
may include patents owned by a corporate entity. A fourth group may include 
patents each having a particular person named as an inventor. A fifth group may 
include patents owned by a competitor. A sixth group may include patents 
related to a research project. A seventh group may include licensed patents. An 
eighth group may include patents and/or non-patent documents related to a 
litigation in which the customer is involved or has an interest (such a group is 
also herein called a case). A ninth group may include patents and other 
documents arbitrarily selected by a customer. 

The present invention is capable of automatically processing the patents 
in a group, or die patents in multiple groups (alternatively, the invention can 
automatically process a single patent). Accordingly, the present invention is said 
to support "group-oriented" data processing. 

As noted above, according to the present invention, processing of the 
patent information 104 is conducted with consideration of other information 106, 
116, 114, 110, 108, called non-patent information. The process of assigning 
patents to groups is an example of processing patent information with non-patent 
information. This is the case, because groups are often created according to non- 
patent considerations. Accordingly, any subsequent processing of the patents in 
a group involve, by definition, non-patent considerations. 
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A group may also contain non-patent documents. In fact, a group may 
contain only non-patent documents. Accordingly, a group is more generally 
defined as a collection of documents (such as patent documents only, non-patent 
documents only, or a combination of patent and non-patent documents). The 
5 documents in a group typically follow a common theme or characteristic 

(although this is not a mandatory requirement of groups). Referring to FIG. 1, 
the invention processes document information 104 alone, or in conjunction with 
other information 106, 1 16, 1 14, 1 10, 108 (which may or may not be related to 
the documents). Accordingly, the processing performed by the present invention 
10 is more generally described as being document-centric and group-oriented. 

Components of the Invention 



FIG. 2 is a block diagram of a system 202 according to an embodiment of 
the invention. The system 202 includes a plurality of databases 216 that store 
patent information and other information, such as R&D (research and 

15 development) information, financial information, licensing information, 

manufacturing information, HR (human resources) information, and any other 
information that may be pertinent to the analysis of the patent information. The 
terms "database" and "table" are used synonymously herein. 

An enterprise server 214 accesses and processes the information in the 

20 databases 216. In particular, the enterprise server 2 14 includes modules that are 

capable of automatically accessing and processing the information in the 
databases 216 in a patent-centric (or document-centric) and group-oriented 
manner. These modules are also capable of automatically accessing and 
processing the information in the databases on a patent by patent basis ("one 

25 patent at a time"). Such processing includes, but is not limited to, reporting, 

analyzing, and planning. 
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The system 202 preferably includes two types of clients, network clients 
206 and web clients 204. These clients 204, 206, pursuant to instructions from 
human operators or users (not shown), interact with the enterprise server 214 to 
access and process the information in the databases 2 1 6. For example, the clients 
204, 206 may request that the enterprise server 214 retrieve certain information, 
or automatically analyze certain information. The enterprise server 2 14 performs 
the requested tasks, and sends the results to the requesting clients 204, 206. The 
clients 204, 206 present these results to their respective operators, and enable the 
operators to process the results. 

In an embodiment of the present invention, the components of the present 
invention shown in FIG. 2 are implemented using well known computers, such 
as a computer 702 shown in FIG. 7. The computer 702 can be any commercially 
available and well known computer capable of performing the functions 
described herein, such as computers available from International Business 
Machines, Apple, Silicon Graphics Inc., Sun, HP, Dell, Compaq, Digital, Cray, 
etc. 

The computer 702 includes one or more processors (also called central 
processing units, or CPUs), such as a processor 706. The processor 706 is 
connected to a communication bus 704. The computer 702 also includes a main 
or primary memory 708, preferably random access memory (RAM). The primary 
memory 708 has stored therein control logic 710 (computer software), and data 
712. 

The computer 702 also includes one or more secondary storage devices 
7 1 4. The secondary storage devices 714 include, for example, a hard disk drive 
7 1 6 and/or a removable storage device or drive 718. The removable storage drive 
718 represents a floppy disk drive, a magnetic tape drive, a compact disk drive, 
an optical storage device, tape backup, ZIP drive, JAZZ drive, etc. 

The removable storage drive 718 interacts with a removable storage unit 
720, As will be appreciated, the removable storage unit 720 includes a computer 
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usable or readable storage medium having stored therein computer software 
(control logic) and/or data. The removable storage drive 718 reads from andJor 
writes to the removable storage unit 720 in a well known manner. 

Removable storage unit 720, also called a program storage device or a 
computer program product, represents a floppy disk, magnetic tape, compact disk, 
optical storage disk, ZIP disk, JAZZ disk/tape, or any other computer data storage 
device. Program storage devices or computer program products also include any 
device in which computer programs can be stored, such as hard drives. 

In an embodiment, the present invention is directed to computer program 
products or program storage devices having software that enables the computer 
702 to perform any combination of the functions described herein. 

Computer programs (also called computer control logic) are stored in 
main memory 708 and/or the secondary storage devices 714. Such computer 
programs, when executed, enable the computer 702 to perform the functions of 
the present invention as discussed herein. In particular, the computer programs, 
when executed, enable the processor 706 to perform the functions of the present 
invention. Accordingly, such computer programs represent controllers of the 
computer 702. 

The modules of the invention discussed herein, such as the grouping 
module 312, the analysis modules 316, etc., preferably represent software 
executing in the computer 702. 

The computer 702 also includes a display unit 722, such as a computer 
monitor, and one or more input devices 724, such as a keyboard, a mouse, other 
pointing devices (such as a light pen and trackball), etc. 

The computer 702 further includes a communication or network interface 
726. The network interface 726 enables the computer 702 to conmiunicate over 
communication networks, such as networks 208 and 212, which preferably use 
the well known HTTP communication protocol. 
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Databases 

FIG. 4 illustrates the databases 216. According to the present invention, 
the databases 216 store document information (that includes patent information) 
and information pertinent to the analysis of the document information. 

FIG. 4 illustrates a particular embodiment of the databases 216, and also 
illustrates a particular embodiment of the types of tables that the databases 216 
contain, and the attributes in the tables. It should be understood, however, that 
the invention is not limited to the particular database embodiment of FIG. 4. 
Instead, the invention is adapted and intended to cover other database structures 
and organizations that are capable of storing document information and 
information pertinent to the analysis of the document information. The particular 
information that is stored in the databases is implementation dependent and varies 
based on a number of factors, including the type of analysis that is desired, the 
specific needs of the customer, the type and content of the information that the 
customer maintains, etc. 

Many of the databases 216, such as the BOM databases 426, the inventor 
databases 428, and corporate entity databases 430, the financial databases 438, 
the person databases 432, and the employee databases 434, are initially loaded 
using information provided by the customer. Such information includes R&D 
(research and development) information, financial information, licensing 
information, manufacturing information, HR (human resources) information, and 
any other information that may be pertinent to the analysis of the customer's 
patents and other relevant documents. After initial loading, these databases 216 
are updated as necessary to reflect changes in the customer's information. 

Other information, such as information for the patent bibliographic 
databases 404 and the patent database 414, may be loaded using information 
provided by a third party provider, such as a third party provider that specializes 
in the provision of patent information in electronic form. One such third party 
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provider is SmartPatents Inc. (SPI) of Mountain View, CA. The patent 
bibliographic databases 404 may be periodically updated through a subscription 
service from such third party providers. Similarly, the patent database 414 may 
be augmented through as-needed orders to the third party providers. It should be 
understood that the present invention works equally well with data provided by 
any party as long as the data's format matches the formats of the patent 
bibliographic databases 404 and the patent database 414. 

Document Databases 

The document databases 4 1 2 preferably include electronic representations 
of documents of interest to the customer. The document databases 412 represent 
the customer's repository of documents, and are thus also called the customer's 
document repository. (The "repository" could alternatively represent all 
documents represented in the databases 2 1 6, whether represented in the document 
databases 412 or the bibliographic databases 402.) 

For example, the patent database 414 includes electronic representations 
of U.S. and foreign patents of interest to the customer. These patents may be 
patents owned and/or licensed by the customer, patents owned and/or licensed by 
competitors of the customer, patents that the customer is considering acquiring, 
patents that, for whatever reason, the customer is studying, etc. The patent 
database 414 represents the customer's repository of patents, and is thus also 
called (in some embodiments) the customer's patent repository. 

The patent database 414 preferably has stored therein an image file and 
a text file for each patent represented in the patent database 4 1 4, where the image 
file and the text file are representations of the patent. Details of an embodiment 
of the image file and the text file are described in U.S. Patent No. 5,623,68 1 and 
U.S. Patent No. 5,623,679. 
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The document databases 412 also include electronic representations of 
other documents of interest to the customer, such as depositions, pleadings, and 
prior art references. These documents are respectively stored in a deposition 
database 4 1 8, a pleadings database 416 (generally, pleadings are papers filed with 
5 a court), and a prior art database 420. Text and/or image representations of these 

documents may be stored. These documents may be pertinent to a patent litigation 
that the customer is involved in. 

The documents in the document databases 412 may be text, images, 
graphics, audio, video, multimedia, and/or any other information representation 
10 that can be stored in electronic form. 

It should be understood that the document databases 412 of FIG. 4 are 
shown for purposes of illustration, and not limitation. As mentioned above, the 
document databases 4 1 2 store electronic representations of documents that are of 
interest to the customer. Accordingly, the types of document databases 412 and 
15 the contents of the document databases 412 are, by definition, customer and 

implementation specific. 

Document Bibliographic Databases 

The document bibliographic databases 402 store information about 
documents (as opposed to the documents themselves). More particularly, the 
20 document bibliographic databases 402 store bibliographic information about 

documents. 

Patent Bibliographic Databases 



25 



The patent bibliographic databases 404 store bibliographic data about U.S. 
and non-U.S. patents. Such patent bibliographic data includes, but is not limited 
to, the information on the front page of patents, such as: the patent number, the 
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issue date, the inventors, the title, the assignee, the serial number, the filing date, 
the U.S. and international classifications, the fields of search, the references cited, 
the primary examiner, the assistant examiner, the attorney, the agent, the law 
firm, priority information, related application information, die number of claims, 
5 the number of drawing pages, the patent term, the expiration date, etc. The patent 

bibliographic databases 404 can also include one or more user defined fields that 
can store large amounts of data, such as 32 Kbytes or more of data. 

In an embodiment of the invention, the patent bibliographic databases 404 
store bibliographic information on all U.S. patents. In other embodiments of the 
10 invention, the patent bibliographic databases 404 store patent bibliographic 

information on a subset of all U.S. patents, such as all U.S. patents that are 
available in electronic form from the U.S. Patent Office, or all U.S. patents that 
issued after a certain date. 

Other Document Bibliographic Databases 

15 The document bibliographic databases 402 include store bibliographic 

information on other types of documents that are of interest to the customer. For 
example, if the customer is interested in depositions, pleadings, or prior art 
references, then the document bibliographic databases 402 would store 
bibliographic information on depositions, pleadings, or prior art references in 

20 deposition bibliographic databases 406, pleadings bibliographic databases 408, 

and prior art bibliographic databases 410, respectively. 

Notes Database 

The present invention supports annotation of the documents in the 
document databases 412. More particularly, the present invention allows users 
25 to create and link annotations (also called notes) to any portions of the documents 
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in the document databases 412. Such annotations can include text, graphics, 
images, video, audio, and/or any other information representation that can be 
stored in electronic form. 

The present invention also allows various information to be stored with 
annotations, such as the date of creation, the creator, the date of modification, a 
note title and/or subject, access rights, etc. 

Embodiments of the notes databases 440 are described in U.S. Patent No. 
5,623,679 and U.S. Patent No. 5,623,681. 

Groups Databases 

Information on groups is stored in the group databases 421. Generally, 
a group is a data structure that includes any number of documents that typically 
follow a common theme or characteristic (although this is not a mandatory 
requirement of groups). More particularly, a group is a data structure that 
includes any number of patents that typically follow a conmion theme or 
characteristic (although, again, this is not a mandatory requirement of groups). 
Groups are document-centric, or in many cases, patent-centric. 

There are two classes of groups: predefined groups (also called system 
defined groups) and user-defined groups (also called arbitrary groups). 

Patents (and/or documents) in predefined groups follow a predefined 
theme or characteristic. Database tables, fields, and attributes of a predefined 
group are specific to the predefined theme/characteristic of the predefined group. 
Accordingly, different predefined groups have different database tables, different 
database fields, and different database attributes. Information on predefined 
groups is stored in the predefined or system defined group databases 422. 

Patents (and/or documents) in user-defined groups may or may not follow 
a common theme or characteristic. Any theme or characteristic that they do 
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follow is defined by the user. Accordingly, user-defined groups are also called 
arbitrary groups. 

All user-defined groups have the same, generic database tables, fields, and 
attributes. However, users may elect to use these database tables, fields and 
attributes differently for different user-defined groups, Information on user- 
defined groups is stored in the user-defined group databases 424. 

Enterprise Server 

The enterprise server 214 is preferably implemented as one or more 
computers (such as the computer 702 shown in FIG. 7) each having at least 128 
MBytes of main memory 708 and running Microsoft Windows NT. The 
enterprise server 214 could, alternatively, be implemented using other memory 
configurations, and other operating systems, such as (but not limited to) UNIX, 
Windows 95, MS-DOS, the Apple Operating System, etc. Accordingly, the 
specific hardware and software implementations discussed herein are provided 
for purposes of illustration, not limitation (this applies to all specific hardware 
and software implementations discussed herein, both for the enterprise server 2 14 
and for other components of the invention). The invention can utilize any 
hardware, software, and operating system capable of performing the functions 
described herein. 

Document Storage and Retrieval Module 

The document storage and retrieval module 308 in the enterprise server 
214 stores and retrieves documents from the document databases 412. 



Notes Module 
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The notes module 314 manages and interacts with the notes databases 

440. 

The client notes module 5 14 enables a user to view and manipulate notes. 

Searching Module 

The searching module 310 in the enterprise server 214 interacts with a 
search engine 324 to conduct searches through the data in the databases 216 
pursuant to search requests from the clients 204, 206. 

Grouping Module 

The grouping module 312 in the enterprise server 214 manages and 
interacts with the group databases 421. 

Analysis Modules 

The analysis modules 3 16 are shown in FIG. 6. These analysis modules 
3 1 6, which are also called methodology modules 3 1 6, automatically interact and 
process data contained in the databases 216 pursuant to user commands. 

Databases 

The database structures of the document bibliographic databases 402, the 
group databases 421, the person databases 432, the employee databases 434, the 
security databases 436, the financial databases 438, and the methodology support 
databases 442 are shown in FIGS. 8B-8M. These figures also depict the 
interaction and connection between these databases. FIG. 8A illustrates the 
preferred orientation of FIGS. 8B-8M with respect to one another. 
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It should be understood that the tables and attributes shown in FIGS. 8B- 
8M only represent one embodiment of the present invention. The data in the 
databases 216 could be stored using other combinations of tables and attributes. 
Such other combinations of tables and attributes will be apparent to persons 
skilled in the relevant arts based on the discussion contained herein. Accordingly, 
the tables and attributes are shown in FIGS. 8B-8M only for purposes of 
illustration, and not limitation. 

Financial Module 

The financial modules 610 in the enterprise server 214 perform patent- 
centric and group-oriented processing of the data in the financial databases 438. 
Examples of the functions performed by the financial modules 610 include 
determining the research and design (R&D) expenditures on a product or product 
line basis, determining the R&D expenditures per inventor or per employee on 
a product or product line basis, determining net licensing revenue on a product 
or product line basis, determining the number of patents issued on a product or 
product line basis, determining patent maintenance fees on a product or product 
line basis, determining market share on a product or product line basis, 
determining the tax rate on a product or product line basis, determining marketing 
costs on a product or product line basis, determining selling costs on a product 
or product line basis, determining the number of outstanding shares (P/E) on a 
product or product line basis, determining revenue on a product or product line 
basis, determining cumulative product revenue on a product or product line basis, 
etc. The financial modules 610 can also perform the above processing on a 
geographical region basis, or on a time basis. 



Console 
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FIG. 9 illustrates a console according to an embodiment of the invention. 
The console 902 includes a first window or pane 904, a second window or pane 
906, and a third window or pane 908. The first pane 904 is also called the group 
pane 904, the second pane 906 is also called the document pane 906, and the third 
pane 908 is also called the notes pane 908. 

A group hierarchy is depicted in the group pane 904. In the example of 
FIG. 9, the top level or root group in the group hierarchy is called the repository 
group 910. The child groups of the repository group 910 are not shown in FIG. 
9 (i.e., the operator has not expanded the repository group 910 in the group pane 
904). The child groups of the repository group 910 are shown in FIG. 133 (i.e., 
the operator has expanded the repository group 910 in the group pane 904 in the 
example of FIG. 10). 

Referring again to FIG. 9, the document pane 906 includes a list of patents 
and other documents which are contained within a group selected from the group 
hierarchy depicted in the group pane 904. The patents and documents are listed 
in a tabular or "spreadsheet" format. The list of patents and documents in the 
document pane 906 includes both the patent numbers and patent bibliographical 
information for the patents, and bibliographic information for the non-patent 
documents. Such patent bibliographic information displayed in the document 
pane 906 includes the title, abstract, inventor, class, issue date, and user-defined 
keywords. All additional patent bibliographic information can be viewed in the 
document pane 906 by utilizing the horizontal scroll bar 920 to sideways scroll 
in the document pane 906, Other embodiments of the invention allow the user 
to select an arbitrary number of bibliographic fields to view. In example of FIG. 
9, no patents are listed in the document pane 906 because a group has not been 
selected in the group hierarchy depicted in the group pane 904. 

The notes pane 908 displays a list of the notes associated with either a 
group selected in the group pane 904, or a patent or document selected in the 
document pane 906. The list of notes in the notes pane 908 is presented in a 
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tabular or "spreadsheet" format. The list of notes in the notes pane 908 includes 
information that identifies the type of the note (that is, either a patent/document 
note or a group note), and the title of the note. All other bibliographic or other 
information relating to notes can be viewed by manipulating the horizontal scroll 
bar 922 in order to sideways scroll in the notes pane 908. 

Licensing Module 

As shown in FIG. 11 A, an embodiment of the invention includes a 
licensing module 1102 (also herein called the licensing system 1102). The 
licensing module 1102 is also referred to herein as the SmartPatents Prism'^'^ 
system. 

Customers use the licensing module 1102 to manage their intellectual 
property (IP) assets for maximal value through the creative use of licensing. The 
licensing module 1 102 provides the tools a licensor needs to manage its licensing 
effectively through tracking a variety of objects, including but not limited to 
out-licenses (i.e., licenses where the corporate entity is the licensor), in-licenses 
(i.e. , licenses where the corporate entity is the licensee), licensing parties (i.e. , any 
parties involved with a license agreement, such as the licensee(s), the licensor(s), 
license agents, license organizations, attorneys, etc.), royalty statements, royalty 
payments, etc. 

Customers also use the licensing system 1 102 to better understand how 
they are making strategic use of their IP assets and to audit the licensees' 
contribution to the value of those assets. 

As shown in FIG. 12, in an embodiment of the invention the licensing 
module 1 102 is a standalone system, existing and operating independently of the 
enterprise server 214 and the enterprise databases 216. In this standalone 
configuration 1201, the licensing module 1102 does not access data in 
enterprise/IP AM database 216. Instead, the licensing module 1 102 utilizes data 
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in its own databases, i.e., a licensing database 1204 and a core database 1208, 
among potentially others. These databases are described in detail below. (The 
invention is not limited to the arrangement of data described herein. In other 
embodiments, the data and attributes described herein are stored in combinations 
of databases and tables other than that described herein.) 

As shown in FIG. 1 3, in another embodiment, the licensing module 1 102 
interacts with the enterprise server214 and/or the enterprise databases216, such 
that users of the licensing module 1 102 may access and utilize groups and/or IP 
assets, as well as other information, stored in the enterprise databases 216, and/or 
may interact with the enterprise server 214 to further manage groups of IP assets 
and/or other objects that are being tracked through the licensing module 1 102. 

According to some embodiments of the invention, the enterprise server 
214 is herein also sometimes referred to as the Intellectual Property Asset 
Manager™ (IPAM™) server 214. 

The database architecture associated with the licensing module 1102 
includes a number of databases. As noted above, the standalone embodiment of 
the licensing module 1102 (shown in FIG. 12) includes a Licensing database 1204 
and a Core database 1208. 

The IPAM-integrated embodiment of the licensing module 1 102 (shown 
in FIG. 13) includes the Licensing database 1204. The Core database 1208 is 
substantially or completely replaced with the enterprise database 216 (also called 
the DP AM database 216). The Core database 1208 contains standalone versions 
of all of or at least a subset of the tables included in the IPAM Server database 
216. Accordingly, when the IPAM database 216 is available, there is little or no 
need for the core database 1208, 

In an embodiment, the licensing module 1 102 is implemented as a two- 
tier client/server model. In an alternate embodiment, the licensing module 1 102 
is implemented as a three-tier model using standard middleware technology such 
as CORBA or COM along with technologies compatible with them, including the 
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appropriate security manager for the application server middleware layer. The 
invention is not limited to these embodiments. The architecture preferably 
provides a thin-client C++ component, a secure application domain server, and 
a secure database server (such as a SQL Server), linking the latter two 
components with ODBC for maximal portability. The user interface and object 
model are tightly integrated and use well known component technologies such as 
ActiveX and DAO. In an embodiment, security relies on defining SQL Server 
database users with passwords and appropriate privileges on the database objects. 

An example thread of operation of the licensing module 1 102 shall now 
be generally described. At initial set up of the licensing module 1102, and 
periodically thereafter (or as the circumstances dictate), a License Administrator 
and a System Administrator must perform various set up tasks, such as entering 
territories, fields of use, and currency conversion intervals. 

After initial set up, the customer enters IP business related information, 
such as but not limited to existing license agreements, new license agreements, 
and/or related objects, such as but not limited to assets, asset packages, contacts, 
compensation terms, and so on. Specifically, in an embodiment, the Data Entry 
Clerk enters assets, and the License Administrator creates asset packages to 
package assets for licensing. The Data Entry Clerk enters contacts by entering 
organizations, people, and contact methods. Then the Data Entry Clerk enters the 
license information. At that point, the License Administrator takes over to modify 
the license agreement with more complex data that requires an understanding of 
licensing. 

As data grows, the License Administrator begins querying the system 
interactively in response to questions and issues that arise. He or she will also 
start generating reports. At some point, an auditor or other interested party will 
also query and generate reports. The License Administrator then may need to do 
some maintenance on the agreements, accompanied by occasional maintenance 
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by the IP AM Administrator on objects that require Administrator privileges to 
remove. 

As time goes on, licensees submit royalty statements and payments. The 
Data Entry Clerk enters these. The License Administrator then allocates the 
payments to expected revenue and to royalty statement details. This linking 
enables the Licensing module 11 02 to generate meaningful revenue reports. 

More generally, the licensing module 1 102 enables users to manage, track, 
interact with, process, analyze, etc., intellectual property (IP) related transactions. 
In a preferred embodiment, such DP related transactions include the licensing of 
IP assets, and the management, tracking, interaction with, processing, analysis, 
etc., of such licensing activities using license agreements, asset packages, royalty 
statements, payments, etc. However, the invention is not limited to this 
embodiment. Instead, the invention is intended and adapted to cover the 
management, tracking, interaction with, processing, analysis, etc., of IP related 
transactions using any object, vehicles, data, etc., in accordance with the scope 
and spirit of the functions described herein. 

The Licensing module 1 102 includes a number of features, including but 
not limited to the following: 

° Import/Export: Support for loading various kinds of objects into 
the Licensing databases from flat files in a standard format to reduce the need for 
extensive data entry (or, worse, reentry). 

° Strategic analysis: Features that help license administrators and 
marketers to understand the strategic implications of licensing their intellectual 
property. This includes offering a database of SEC lOK filings of "material" 
license agreements on which you can search to determine the range of royalty 
terms and the strategic issues that arise in a specific industry. 

° Market opportunity tracking: Tracking of sales opportunities 
related to contacts, including inquiries, targeted potential customers, and 
infringement tracking. 
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° Marketing Communications and Sales support: Support for 
customer inquiries, IP marketing brochure querying, and e-commerce sales 
support. 

Asset types: Support for more asset types, particularly in the arena 
of Know How. In an embodiment, Know How is a class with various kinds. In 
alternate embodiments, subclasses are created for the broad areas within Know 
How such as Technical Data, Technical Assistance, Process, Software, and other 
such categories with specific attributes. 

° Electronic Data Interfacing: support for the ability to transfer 
royalty statements and payments from licensee to licensor automatically through 
the Internet or other communications media to improve compliance, simplify 
auditing, and reduce data entry requirements. 

° Licensing In: Extensive support for the licensee, including royalty 
statement generation, payment due flagging, and sublicense tracking. 

° Compliance workflow: Support for the contract administrator in 
monitoring the compliance of agreement parties to the terms and conditions of the 
license agreement, such as generating royalty invoices, checking revenue 
numbers, and detailed representation of contract clauses and their compliance 
requirements 

° Sublicense tracking: The ability to track sublicensing of a hcense 
agreement for better royalty tracking and control and contract compliance, 

° Contract development workflow: Support for user-defined 
templates for license agreements and generation of standard agreements with 
designated clauses. 

°. International licensing support: support for various issues that 
arise with international licenses, including support for offset licensing ("counter 
trade" or "industrial participation" licensing) and the various registration 
requirements for copyrights, trademarks, and patents in foreign countries and the 
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import/export requirements of foreign governments that impact royalty and fee 
payments. 

° Custom report integration: the ability to integrate custom reports 
into the Reports View and run them along with standard reports. This includes 
5 integration of a complete report writer into the Licensing module 1 102. 

° Administrative audit trails: support for object version auditing 
through recording the user and timestamp for each change to the persistent data. 

° Help Desk support: Extensive support for internal customers of the 
system getting answers to basic questions through query facilities in the Licensing 
10 module 1 102, ranging from a simple frequently-asked-question style to the ability 

to query information about licenses, royalty statements, and payments. 

° Valuation: Support for alternative methods of valuing a license 
and its licensed assets. 

The licensing module 1 102 is described in greater detail in the following 
15 sections. 

User Roles 

Generally, the licensing module 1 102 involves a number of user roles, 
including but not limited to the following. The invention is not limited to these 
functions being performed by the people specified below. In other embodiments, 
20 other people in other user roles can perform the following functions. 

° The Data Entry Clerk: a user who enters basic data about contacts, 
licenses, royalty statements, and license payments. Generally, a Data Entry Clerk 
does not require much knowledge about licensing or intellectual property. 

° The License Administrator: a user who enters more complex 
25 information about licenses, royalty statements, and payments and who works with 

executives, corporate counsels, licensees, and others to provide information about 
the licenses and revenue in the BP AM system 1102. Generally, a License 
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Administrator requires extensive knowledge about licensing and licensed 
intellectual property. 

The Auditor: a user who generates summary and detail reports 
about the licenses and their associated revenue and who queries information 
interactively to investigate specific issues. Generally, an Auditor requires 
extensive knowledge about licensing and the details of accounting for license 
revenue, but does not require write access to the system. 

The System Administrator: a user who handles security 
management, data entry of supporting database information, and cleanup of the 
database on demand from others. 

The Database Administrator: a user who sets up and controls the 
physical layout of the database that the Hcensing module 1 102 uses. 

Generally, the System and Database Administrators have full access to 
everything in the system. The other users have access granted to them by owners 
of asset packages or those with write access to security classifications. The 
different roles above do not imply any particular security access; each user has 
whatever access they are granted by the Administrator or other users. 

FIG. 15 illustrates an object-oriented view of a preferred actor hierarchy 
1502 for the licensing system 1 102. As FIG. 15 illustrates, all actors inherit the 
base capabilities of a generic user 1504, who may be a user of the licensing 
system 1102. This user, for example, could have the authority to view data, 
conduct searches, and run reports. Other actors, such as the system administrator 
1506, the data entry clerk 1508, the auditor 1512, and the database administrator 
1516, have capabilities above and beyond that of the user 1 504. These additional 
capabilities are elaborated above, and further indicated below. A super user, the 
licensing administrator 1518, preferably has complete access to the licensing 
system 1 102, and thus is shown in FIG. 15 as inheriting all the capabilities of all 
the other actors. 
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Architecture 

FIG. 1 IB is a block diagram of the licensing system 1 102 according to an 
embodiment of the invention. 

There are three general functions of the Licensing module 1 102: data 
entry, data exploration, and reports. Underneath the user interface, there is an 
object model that implements all the different kinds of licensing objects that 
Licensing module 1 102 needs to support data entry, to provide exploration of the 
database, and to permit generation of effective reports. Licensing module 1 102 
preferably connects to a SQL Server database server 1 140 through ODBC 1 138 
to provide persistent storage of its data and to support third-party report 
definitions. 

User Interface 

The user interface preferably includes the following components. 

Licensing System User Interface Module 

The licensing system user interface module 1101 is the primary user 
interface for the licensing related functions of the licensing system 1 102 
described herein. The licensing system user interface module 1 101 interacts with 
users via the windows and dialogs described herein. Preferably, the licensing 
system user interface module 1 101 is written in Visual C++ and MFC (Microsoft 
Foundation classes, a well known class library for Visual C++), although the 
invention is not hmited to this implementation. 

Licensing System Administrator User Interface Module 
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The licensing system administrator user interface module 1 104 is the user . 
interface to the licensing related administrative functions described herein. The 
licensing system administrator user interface 11 04 is preferably written in Visual 
C-H- and MFC, although the invention is not limited to this implementation. 

Data Entry 

In an embodiment, operation of the licensing module 1102 is based on 
license agreements. (The invention is not limited to this embodiment. 
Specifically, in other embodiments, the licensing module 11 02 is based on other 
IP related transactions, such as assignment agreements, technology transfer 
agreements, security interests, or any other agreement involving a transaction that 
includes or relates to an IP asset.) 

Generally, license agreements are completely nonstandard in text format, 
but customers need to track specific, standard information about the agreement: 
its terms, its duration, its parties, the payments and statements customers receive, 
etc. They need to explore how their IP assets are generating revenue. They need 
to be able to license IP assets including patents, trademarks, copyrights, know 
how, trade secrets, other licenses, etc. Customers need to package multiple 
assets for licensing through a single license. They need to report on different 
aspects of their license portfolio. They need to search the document text to 
identify agreements that they can use as templates for further agreements. 

Consequently, the Licensing module 1102 enables users to enter 
structured data about license agreements, royalty statements, payments (this 
information is preferably stored in the licensing database 1204). The licensing 
module 1102 also enables users to enter data about companies and people to 
which IP assets can be licensed (this information is preferably stored in the 
licensing database 1204). The licensing module 1 102 also enables users to enter 
DP assets (patents and other types) (this information is preferably stored in the 
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licensing database 1204). This part of the licensing system 1 102 can link to the 
IP AM Server 214 for access to the IP assets and groups it supports. The 
licensing module 1 102 also adds to those IP assets as necessary to round out the 
range of asset types that customers wish to license: trademarks, copyrights, and 
trade secrets as well as patents. Generally, information on non-patent assets are 
stored in the licensing database 1204 or the core database 1208. Information on 
patent assets are stored in the IP AM database 216 when working in the IP AM 
integrated mode (FIG. 13), and stored in the licensing database 1204 or the core 
database 1208 when working in the standalone mode (FIG. 12). The Licensing 
module 1102 also provides asset packaging options beyond lists of assets, 
including search packages based on IP AM search groups and descriptive asset 
packages that define asset groups with text rather than enumerating assets. 

Licensing Reports 

Licensing reports are an important feature of the Licensing module 1 102. 
Customers use reports generated by the licensing module 1 102 to track the 
revenue due from licenses, to compare that expected revenue to the actual 
revenue received, and to evaluate the success of license management in their 
business units. The invention also supports other reports. 

Preferably, the report generation module 1106 is responsible for 
generating the reports requested by users. The report generation module 1 106 
generates reports using the data in the licensing related databases, including 
printing the contents of each major object in the system (Print License, Print 
Asset, and so on). Preferably, the report generation module 1 106 connects to the 
databases through ODBC 1 138 or through the Microsoft SQL Server driver, for 
example. The report generation module 1 106 can be implemented using a 
commercial report generation product, such as Crystal Reports, although the 
invention is not limited to that embodiment. 
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In embodiments where the report generation module 11 06 is implemented 
using a commercial report generation product, a report generator interface 1 132 
interacts with the report generator 1106 to cause the report generator 1106 to 
generate reports per user instructions. For example, the generator interface 1 1 32 
may interact with the report generator 1 106 in a manner consistent with the API 
(application program interface) of the report generator 1 106 to cause the report 
generator 1 106 to access the databases 1608 for appropriate information, and to 
process and format that information in reports, per user commands. 

Data Exploration Module 

Strategically, licensing managers will use the Licensing module 1 102 to 
access license data in creative ways. 

A strategic use of the licensing system 1102 involves ad-hoc query 
functions in combination with reports to identify IP assets that are 
underperforming or outperforming and to cross-reference between license 
agreements, licensees, royalty terms, royalty statements, and royalty payments. 
The ad-hoc query facility uses the same user interface that provides data entry 
facilities in an easy-to-use query-by-example format. 

The ad-hoc query facilities also support licensing personnel and auditors 
in interactive tactical tracking down of issues such as payments due, payments not 
received, royalty statement details, and errors in data entry. 

Object Model 

The object model of the Licensing module 1 102 represents the transient 
aspect of the persistent data in the database server. The subsystems of the object 
model provide interfaces to the various licensing-related objects and higher-level 
objects that aggregate them for use in the Licensing module 1102. The object 
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model supports a number of subsystems and/or object/data types, including but 
not limited to the following: 

° Entity 1112: The people and corporate entities that make up the 
licensors, licensees, and other parties to the license agreement. 

° Contact: The contact-related information for entities. 

Role: The relationships between entities and other subsystems. 

° Agreement 1114: The licensing agreement, including basic royalty 
terms and advanced royalty structures. 

° Package 1 1 1 8: IP assets and their groupings, including enumerated 
groups of license agreements, groups based on a search condition from the IP AM 
Server, and descriptive groupings. 

° Royalty 11 20: The royalty statement that details the responsibility 
of the licensees for royalty payments. 

° Payment 1122: The payments received from entities related to 
licenses and their links to the general ledger. 

More particularly, the licensing system domain 1 108 is an object layer 
called a licensing system domain 1 108 that represents a series of subsystems 
(generally indicated as 1 148 in FIG, 1 IB) that contain objects that the licensing 
system 1 102 requires to provide the functionality described herein. Preferably, 
each subsystem design minimizes the connections to other subsystems from its 
internal objects with the objective of maximal reusability as components. Each 
subsystem provides a complete interface to the subsystem and its component 
objects. Each subsystem is preferably a separate DLL (dynamic link library) and 
is preferably contained within a separate C-h- namespace. 

Each subsystem exports a set of Transaction subclasses, where a 
transaction is a Database subsystem component that provides support for database 
transactions. Each transaction subclass represents a transaction use case. Some 
transaction classes provide methods for generating objects either as new objects 
or as objects queried from the database. Others provide the ability to update and 
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delete objects from the database. Each use case is a single transaction through the 
system, and each must execute entirely within a single thread to ensure thread 
safety. The use cases supported by an embodiment of the invention are described 
in sections below. 

5 The user interface accesses the transaction subclasses as the primary 

interfaces. Transactions correspond to the work the user does with those objects 
(entering new assets, adding payments to a license, and so on). Block diagrams 
of the subsystems are illustrated in FIGS. 126-150. Details on these subsystems 
will become apparent from the following discussion of use cases. 
10 It is noted that allocation of functions to the subsystems 1 148 may vary 

according to the implementation. Accordingly, the subsystems shown in FIG. 1 1 B 
should be considered only an example. 



Data Access Module 



The data access module 1110 provides an interface between system 
15 databases 1608 and the modules of the licensing system 1 102. Preferably, the 

data access module 1110 includes the Microsoft Active Data Objects COM 
component (preferably version 1.5) that provides a SQL interface for accessing 
various data sources. In this case, it connects to ODBC 1 138. 



Database Architecture 



20 The database architecture preferably includes a Database Server 1 140 

(such as a SQL Server or an Oracle server) that preferably manages the persistent 
data as a set of relational tables. The databases 1608 in the database architecture 
each preferably includes a number of databases, each containing a well-defined 
and reusable set of data components. (It is noted that the invention is not limited 
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to this arrangement of data. In other embodiments, the data described herein is 
stored in database arrangements other than that described below.) 

The Licensing database 1204 contains the Role, Agreement, 
Royalty, and Payment data. More particularly, the licensing database 1204 
contains tables that provide information about licensing-related objects 
(agreements, royalties, payments, currency, and so on). The Licensing database 
1204 also contains the standalone asset data. The Licensing Database 1204 
further includes tables supporting time periods (start date/end date type 
relationships). The licensing database 1204 also contains the Entity and Contact 
data, i.e., data supporting people, organizations, and contact information for them. 
The Licensing database 1204 provides a series of views for tables in all the other 
databases. The domain and the report definitions access the Licensing database 
1204, using the views to access data in the other databases. This provides a 
single, unified database interface for the higher level layers in the licensing 
system 1102. Views in the Licensing database 1204 are preferably integrated 
when necessary to provide easier access to complexly related tables. The 
objective in dividing the tables between several databases is to separate the data 
for reuse in other applications. 

° The Core database 1208, which contains Group data (that is, 
information on groups and the assets in each of the groups) and patent asset data 
(either downloaded from the DP AM Server database 216 or a standalone version 
of that database 2 1 6 that Licensing module 1 102 uses). More generally, the Core 
database 1208 contains exactly the same or, alternatively, substantially the same 
tables that are in the IPAM database 216 (optionally, any databases in the IPAM 
database 216 that are not accessed by the licensing system 1 102 are not included 
in the core database 1208). 

The standalone version of Licensing module 1 102 has a stand-in version 
of the IPAM database 216 (i.e., the Core database 1208) that, in an embodiment, 
contains only some of the tables in that database that the module uses (for 
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example, group, document, and a few miscellaneous tables). The patent tables in 
the IP AM Server database 216 also replaces the patent tables (but not non-patent 
asset tables) in the licensing database 1204 or the core database 1208 for the 
integrated version of the Licensing module 1 102 (FIG. 12). 

FIG. 16 illustrates a conceptual, object oriented view of the databases 
1608. The licensing database 1204, the core database 1208, and the IPAM 
database 216 inherit all the abilities of a generic database 1604. 

Licensing Module As a Standalone Module or Integrated with IPAM 
(IPAM Integrated) 

As discussed above, in one embodiment the Licensing module 1102 
integrates with the IPAM Server 214 through the IPAM database 216, which it 
accesses directly. 

The standalone version of the Licensing module 1 102 replaces the IPAM 
database 216 with a Core database 1208 that emulates the IPAM tables 216 that 
the Licensing module 1102 uses, including the Group-related tables, the 
Document table, the IP Document table hierarchy, and the UDD (unique 
document descriptor) tables. See FIGS. 8A-8M. 

With IP AM integration, the Licensing module 1 102 has all the patent and 
UDD (user defined documents) documents available as assets and all groups 
available for group asset packages from the IPAM database 216. With the 
standalone version of the Licensing module 1102, the customer must enter 
patents through data entry screens in the Licensing module 1 102 interface (in an 
embodiment, these are not present when the system is integrated). 

Preferably, the Licensing module 1 102 integrates with the IPAM security 
system through the IPAM security broker, a library that is part of the IPAM server 
technology. 
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Object Display Window of the User Interface of the Licensing module 

FIG. 14 illustrates an object display window 1402 of the user interface of 
the Licensing module 1102. The object display window 1402 includes a number 
of elements: 

Menus: At the top of the object display window 1402 are a variety 
of pull-down menus 1406. These menus 1406 allow easy access to all of the 
transactions you can accomplish with the Licensing module 1 102 

° Tool Bar: Under the pull-down menus 1406 is a tool bar 1404, 
which presents a line of often-used tools, such as New, Save, Print, and Find. 

° Licensing Functions Tool Bar: Along the side of the object display 
window 1402 is a licensing functions tool bar 1408 that include icons providing 
access to the major objects in the Licensing module 1 102. These icons include 
a license agreements icon 1412, a contacts icon 1414, an asset packages icon 
1416, a royalty statements icon 1418, a payments icon 1420, areports icon 1422, 
and a recycle bin icon 1424. Clicking on one of these icons changes the content 
of the content view area 1426 so as to display the indicated kind of objects and 
the various components that make them up. 

° Content View area: The content view area 1426 is the main area 
of the object display window 1402. The content view area 1426 contains one or 
more controls for managing the objects that make up Licensing module 1 102. 
These panes include spreadsheet views, and one or more "explorer" or 
hierarchical views for organizational structure. A spreadsheet view lets you 
configure the columns to display and sorts on a column when you click on the 
header. 

° Status Bar: A status bar 1410 appears at the bottom of the object 
display window 1402. The status bar 1410 displays application status, short help 
messages, keyboard status (CAPS LOCK, NUM, etc.), etc. 
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° Recycle Bin: If you remove one of the major objects (entity, asset, 
asset package, license, royalty statement, payment, currency, etc.), the object gets 
recorded in the Recycle Bin 1424. You can either restore individual objects in the 
Recycle Bin view, or you can empty the recycle bin 1424 to make the changes 
permanent. An object in the recycle bin 1424 is preferably not visible anywhere 
else in the application. 

° Dialogs: There are various dialogs that pop up (not shown in the 
example of FIG. 14), usually as a result of clicking on a tool button or 
double-clicking on an object in a spreadsheet; the dialogs accomplish data entry, 
data modification, searching, etc. 

Operational Features of the Licensing Module 

Operational functions supported by embodiments of the licensing module 
1 102 are described in detail in the following sections. 

Preferably, these functions are implemented by one or more computers 
operating according to control logic, or software. Such software is preferably 
written in an object oriented manner. Accordingly, the licensing module 1 102 
can be said to be an object oriented system. 

Use cases are sometimes used to describe the manner in which an object 
oriented system works. Generally, a use case describes a transaction processed 
in an object oriented system. 

Use cases often include extensions. Extensions are conditional. For 
example, die enter contact method use case described below extends the enter 
entity method use case. In other words, under certain conditions when you are 
entering an entity, you will enter a contact method. 

In the following section, the functions supported by embodiments of the 
licensing module 1 102 are described by describing use cases that correspond to 
these functions. Coding of software to achieve these functions will be readily 
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apparent to persons skilled in the relevant arts, based on the description contained 
herein, including but not limited to the following description of use cases. In the 
following, use cases are described as being implemented as procedures, but in 
practice the functionality of any number of use cases can be achieved through one 
or more software procedures. 

An embodiment of the licensing system 1 102 is shown in FIG. 1 7 A. Each 
of the ovals shown in FIG. 17 A corresponds to a logical functional module of the 
licensing system 1 102, Generally, these functional modules correspond to the use 
cases that are described below. The relationships between the functional modules 
are indicated in FIG. 17 A. 

The invention also preferably includes a licensing administration module 
1701 (FIG. 17B). The licensing administration module 1701 performs 
administrative tasks associated with the licensing system 1 102. The licensing 
administration module 1701 is preferably accessible only by administrators. 

A functional module may "use" another functional module. In other 
words, in the course of performing its specified function, a functional module 
may call or invoke the services of another functional module. Alternatively, a 
functional module may "extend" another functional module. In other words, a 
functional module may extend the capabilities of another functional modules. In 
some cases, not all relationships between modules are shown in the figures. The 
relationships between functional modules are further described in the following 
sections. 

In the following, certain steps are described as being preferably performed 
by some actors, but in practice and/or in other embodiments, the steps are 
performed by other actors, including but not limited to those described herein. 
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General Purpose Use Cases 

There are several general-purpose use cases that apply to all users or to 
generic objects. These are described in the following sections. 

Login 

The login use case 1802 is diagramed in FIG. 18. 

The User enters his or her user name and password and any connection 
string required by the ODBC data source in a login dialog 1902 shown in FIG. 1 9. 
The licensing module 1 102 logs the user into the server preferably through the 
ODBC connection mechanism and authenticates the user through the IP AM 
security system 1602. 

Display Help 

The display help use case 2002 is diagramed in FIG. 20. 

The User requests help in a specific context or requests display of the help 
contents, index, or query preferably using a standard help system, such as the 
Microsoft Windows help system. The display help module 1704 displays the 
appropriate help screen by accessing, retrieving, and displaying pertinent 
information from a help file 2004. 

Print Object 

The print object use case is diagramed in FIG. 21. 

The Auditor or License Administrator selects an object and prints the 
object in a standard print format to a system printer using the print object module 
1706. 
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The operation of the print object module 1706 is further detailed below: 

Step 1 : The Auditor or License Administrator (the Actor) starts the read- 
only transaction by selecting an object (license agreement, asset package, entity, 
royalty statement, or payment), and then selects the Print command. 

Step 2: The print object module 1706 displays a Print <Object> dialog, where 
<Object> is one of the five basic objects fix)m step 1 . 

Step 3: The Actor sets the printing options, including any printer setup 
commands, then issues the instruction to print, ending the transaction. 

Step 4: The print object module 1706 prints the object. 

If the Actor in step 1 selects a License Agreement, the Print License use case 
extends the print object module 1706. 

If the Actor selects an Asset Package, the Print Asset Package module 1710 
use case extends the print object module 1706. 

If the Actor selects an Entity, the Print Entity module 1708 extends the print 
object module 1706. 

If the Actor selects a Royalty Statement, the Print Statement module 1 7 1 4 use 
case extends the print object module 1706. 

If the Actor selects a Payment; the Print Payment module 1716 extends the 
print object module 1706. 

Contacts 

A Contact is an organization or person (general term "entity", which also 
encompasses users and user groups in the security system). People play roles in 
organizations, and both people and organizations have contact methods (telephone, 
mail address, and email). 

A Contact View 2202 is displayed by selecting the contacts icon 1414 (FIG. 
22). The contact view 2202 contains two panes, an explorer view (organization pane) 
2204 of organizations and a list of people (people pane) 2206. It is possible to expand 
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and contract the organization hierarchy in a well known manner. When you select an 
organization, the people in that organization appear in a people list pane 2206 in a 
tabular spreadsheet format.. 

Double-clicking on an organization in the explorer view 2204 displays the 
data modification dialog for organizations. Double-clicking on a person in the people 
list pane 2206 displays the data modification dialog for people. You can double-click 
on an empty record or click the New button to create a new organization or person. 

The Licensing System Administrator creates, modifies, and/or removes roles 
fix)m the Licensing Database 1204. 

Enter Entity 

The enter entity use case 2302 is diagramed in FIG. 23. 

The Data Entry Clerk enters entity information for people and organizations, 
including orgaruzation levels, people's names, and (optionally) contact methods. The 
Data Entry Clerk may optionally link a person to an organization with a specific role. 

The enter entity use case 2302 is further described below: 

Step 1 : The Data Entry Clerk begins the transaction. 

Step 2: The enter entity module 1718 displays the organizations in the 
organization pane 2204 and people in the people pane 2206 stored in the licensing 
database 1204 using the Display Entities module 1722. 

Step 3: The Data Entry Clerk takes any of these actions (for example): 

Step 3. 1: The Data Entry Clerk adds an organization to the list of 

organizations. 

Step 3.2: The Data Entry Clerk adds a new person to a list of people 
for an organization. 

Step 3.3: The Data Entry Clerk copies an existing f)erson into a new 

organization. 
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Step 4: The enter entity module 1718 displays a data entry form and creates 
a new entity unique identifier. 

Step 5: The Data Entry Clerk enters an optional description for the new 
organization/person. 
5 Step 6: The Data Entry Clerk commits the transaction. 

Step 7: The licensing system 1 102 stores the entered entity information in the 
hcensing database 1204 and confirms the conunit to the Data Entry Clerk. 

There are a number of extensions to the enter entity module 1718. 

° For a person, the Data Entry Clerk enters the First Name, Middle 
10 Name, and/or Last Name. 

** For an organization, the Data Entry Clerk enters the Name. Optionally 
for an organization, the Data Entry Clerk enters the date on which the organization 
came into existence. 

° Optionally for an organization, the Data Entry Clerk chooses an 
15 organizational level from a list. 

° If the Data Entry Clerk wants to enter contact information for the 
entity, the Enter Contact Method use case extends this use case. 

° If the Data Entry Clerk is entering a person and wants to link that 
person to an organizational role, the link Person to Organizational Role use case 
20 extends this use case. 



Enter Contact Method 

The enter contact method use case 2402 is diagramed in FIG. 24. 
This use case extends or is used by another use case, which supplies the 
unique identifier of an entity. The Data Entry Clerk enters one or more contact 
- 25 methods for that entity. 

The enter contact method module 1720 is further described below: 
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Step 1. The using use case passes in an object identifier for an entity with 
which to associate a contact method. 

Step 2. The Data Entry Clerk chooses one of three types of contact method: 
telephone, email, or mail address. 

Step 3. The enter contact method module 1720 displays an entry form 
appropriate for the type of contact method selected and generates a unique priority, 
defaulting it to one more than the last priority entered for methods associated with this 
entity: 

SELECT MAX(Priority)+l 
FROM Contact_Method 
WHERE Entity,© = :Entity_ID 
where :Entity„ID is the entity object identifier passed into this use case. Note: The 
Data Entry Clerk can modify the priorities in the Modify Entity use case. 

Step 4. The Data Entry Clerk optionally enters a Description for the contact 
method and terminates the use case. 

Step 5. The enter contact method module 1720 inserts the contact method 
into the Licensing Database 1204, linking the entity and contact method. 

There are a number of extensions with this use case: 

° If the contact method is telephone, the Data Entry Clerk enters a 
country code (default 1), an area code, a telephone number, and (optionally) an 
extension and whether the phone is a fax line. 

° If the contact method is email, the Data Entry Clerk enters a domain 
and an address. 

° If the contact method is a mail address, the Data Entry Clerk enters 
a street address, a city, a state or province, and a country (default = USA). Optionally, 
the Data Entry Clerk enters a second line of street address and/or a postal code. The 
Clerk can enter this data in any order. 

° If the Data Entry Clerk presses Fl or the equivalent, the application 
extends the use case with the Display Help use case. 
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Display Entities 

The display entities use case 2502 is diagramed in FIG. 25. 

The Enter Entity niodule 1718 and Modify Entity module 1728 both use the 
display entities module 1 722 to display organizations and people. The display entities 
module 1722 displays a tree of organizations and displays all the people in an 
organization that the Data Entry Clerk selects. 

The display entities module 1722 is further described below: 

StepL The display entities module 1722 displays a list of top level 
organizations in alphabetical order from the Licensing database 1204 in the 
organization pane 2204 of the contact view 2202, The display entities module 1 722 
then displays in the organization pane 2204, for each organization, the hierarchy of 
organizations that have the top-level organization as a parent. 

Step 2. The Data Entry Clerk selects an organization from the organization 
pane 2204. 

Step 3 . The display entities module 1 722 displays in the people pane 2206 an 
alphabetical list of all the people in the organization from the Licensing database 
1204, preferably displaying the Entity unique identifier, the entity Name, the entity 
Description, the role Name, and the Start Date and End Date (if any) of the interval 
during which the person played the particular role in the organization, all preferably 
ordered by the last name then first name of the person. The user can select to order 
the data in other ways (this is true whenever data is displayed in the present 
invention). Note that a person may have different roles in the organization, perhaps 
at different times. The display entities module 1 722 displays the person only once but 
supplies a list of roles and time periods for the person with multiple roles. 

Modify Entity 

The modify entity use case 2602 is diagramed in FIG. 26. 
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The Data Entry Clerk interacts with the modify entity use case 2602 to modify 
entity informauon for people and organizations, including organization levels, 
people's names, and contact methods. The Data Entry Clerk may opdonally modify 
the links between a person and their roles in organizations. 

The modify entity module 1728 is further described below: 

Step 1. The Data Entry Clerk begins the transaction by selecting an 
appropriate menu option, or pressing an appropriate dialog button. 

Step 2. The display entities module 1722 displays a list of top level 
organizations in alphabetical order from the Licensing database 1204 in the 
organization pane 2204 of die contact view 2202. The display entities module 1722 
then displays, for each organization, the hierarchy of organizations that have the 
top-level organization as a parent. 

Step 3. The Data Entry Clerk selects an organization. 

Step 4. The display entities module 1722 displays an alphabetical list of all 
the people in the organization from the Licensing database 1204 in the people pane 
2206. 

Step 5. The Data Entry Clerk selects an entity (person or organization) for 
modification. 

Step 6. The modify entity module 1728 displays a data entry form for the 
appropriate kind of entity. 

Step 7. The Data Entry Clerk optionally changes the entity name and/or 
description in any order. 

Step 8. The Data Entry Clerk commits the transaction. 

Step 9. The modify entity module 1728 updates the Licensing database 1204 
with the modified entity information and confirms the commit to the Data Entry 
Clerk. 

This use case has a number of extensions: 
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For a person, the Data Entry Clerk modifies the individual elements 
of the name, which the modify entity module 1728 then concatenates together for the 
Entity Name. 

For an organization, the Data Entry Clerk can optionally modify an 
organizational level from a list. 

Optionally for an organization, the DataEntry Clerk enters or changes 
the date on which the organization came into existence. 

° Optionally for an organization, the Data Entry Clerk links the 
organization to another organization as its parent (the organization the Clerk is 
entering is the child, the other organization is a parent). Preferably, there can be only 
one such parent, so the change modifies any current link. 

° Optionally for a person, the Data Entry Clerk adds, modifies, or 
removes a role in an organization using the Link Person to Organizational Role use 
case, which extends this use case. 

If the Data Entry Clerk wants to enter additional contact information 
for the entity, the Enter Contact Mediod use case extends this use case. This repeats 
as often as necessary. 

** If the Data Entry Cleric wants to change existing contact information 
for the entity, the Modify Contact Method use case extends this use case. This repeats 
as often as necessary. This use case must query the set of contact methods and let the 
Data Entry Clerk identify which one to modify. 

Modify Contact Method 

This use case is diagramed in FIG. 27. 

This use case extends or is used by another use case, which supplies the object 
identifier for an entity and the priority of the contact method for that entity, which 
taken together identify the contact method. The Data Entry Clerk can change any of 
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the characteristics of the contact method, which may be a telephone number, a mail 
address, an email address, etc. 

The modify contact method module 1726 is discussed further below: 

Step 1 . The modify contact method module 1726 accesses a contact method 
5 from the licensing database 1204. The modify contact method module 1 726 displays 

the contact method in a dialog. 

Step 2. The Data Entry Clerk optionally modifies the Description and details 
(see Extensions) for the contact method and terminates the use case. 

Step 3. The modify contact method module 1726 inserts the contact method 
10 into the Licensing database 1204, linking the entity and contact method. 

This use case includes the following extensions: 

° If the contact method is telephone, the Data Entry Clerk enters a 
country code (defauh 1), an area code, a telephone number, and (optionally) an 
extension and whether the phone is a fax line. 
15 ° If the contact method is email, the Data Entry Clerk enters a domain 

and an address. 

° If the contact method is a mail address, the Data Entry Clerk enters 
a street address, a city, a state or province, and a country (default = USA). Optionally, 
the Data Entry Clerk enters a second line of street address and/or a postal code. The 
20 Clerk can enter this data in any order. 

Link Person to Organizational Role 

The link person to organization role use case 2802 is diagramed in FIG. 28. 

This is a use case that extends other use cases when the Data Entry Clerk 
wants to model a particular person's role in an organization during a given period of 
25 time. The extended use case passes in the object identifier for the person and the 

organization. The Data Entry Clerk selects the role from a list of roles and sets the 
time period. 
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This use case is further described below: 

Step 1 . The extended use case passes in the object identifiers for a person and 
an organization. 

Step 2. The link person to organization role module 1724 displays a form 
containing a list of roles ordered by name, displaying the Name and Description for 
each role, and entry fields for Start and End Dates. 

Step 3. The Data Entry Clerk selects a role and enters the Start Date 
(required) and optionally the End Date. 

Step 4. The link person to organization role module 1724 creates a link 
between the person, the role, and the organization in the Licensing database 1204 as 
an instance of Organization People and a time period using the Start and End Dates. 

This use case has a number of extensions: 

° If the Data Entry Clerk supplies only a Start Date, the link person to 
organization role module 1724 creates an Open-Ended Period using that date. 

° If the Data EnU7 Clerk supplies both a Start Date and an End Date, 
the link person to organization role module 1724 creates a Fixed Interval using those 
dates. 

Print Entity 

The print entity use case 2902 is diagramed in FIG. 29. 

This use case extends the Print Object use case. The print entity module 1708 
prints information on an Entity, including all information in the Licensing database 
1204 about the entity, its relationships to other objects, and its contact information. 

The operation of this use case is further described below: 

Step 1. The Actor via the print entity module 1708 selects an Entity and 
selects a command to print it. 

Step 2. The print entity module 1708 prints a formatted report with the Entity 
ID, Name, Description, and Named Entity Type (Organization or Person). 
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Step 3. The print entity module 1708 prints the contact information for the 
entity in priority order, printing the Priority, Description, and Contact Method Type 
for each method. 

Step 4. The print entity module 1708 prints the Role Name and Know How 
5 Description for any Contributor relationship the Entity participates in. 

Step 5. The print entity module 1708 prints the Role Name and Agreement 
Number and Name for any license agreement to which the Entity is a party. 
This use case has a number of extensions. 

If the Entity is an Organization, the print entity module 1 708 prints 
1 0 the parent organization's Name and the Description of the Organizational Level of the 

organization. 

° If the Entity is a Person, the print entity module 1708 prints the 
Organizations to which the Person belongs in order by time period. 

** If the Contact Method is a Telephone, the print entity module 1708 
15 prints the number in the format "-KCountry Telephone Code > <Area Code> 

<Telephone Number> x<Extension>." If Is Fax is true, the print entity module 1708 
adds "(facsimile)" to the string. 

If the Contact Method is an Address, the print entity module 1708 
prints the address in the format "<Address 1>, <Address 2>, <City>, <State or 
20 Province>, <Country Abbreviation>, <Postal Code>". 

If the Contact Method is an Email, the print entity module 1 708 prints 
the address in the format "<Address>@<Domain>". 

Remove Entity 

The remove entity use case 12102 is diagramed in FIG, 121. According to 
25 this use case, the Licensing system Administrator selects an entity and removes it 

from the Licensing database 1204. Preferably, an entity can be removed only if it 
does not participate as a party to a license agreement or as a contributor to a 
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know-how asset. In removing an entity, a number of different objects are also 
removed: 

° The entity's contact methods 

Organization or person corresponding to the entity 

° Links fix)m the entity to an organization/role combination 

° Name fragments associated with the person 

The operation of this use case is further described below. 

Step 1. The License Administrator begins the transaction. 

Step 2, The Remove entity module 1794 displays a list of existing entities 
ordered by name, displaying the name and entity type. 

Step 3. The License Administrator selects an entity and removes it. This is 
allowed only if the entity is not associated with a license (no rows in the Party table 
for this entity) or has no payments (no rows in the Payment table with Payor_ID = 
OID) . The License Administrator can select and remove multiple entities at once or 
in sequence. At the end of the process, the License Adminisu^tor commits the 
transaction. 

Step 4. The Remove entity module 1 794 deletes die entity, removing also the 
corresponding subclass (Person or Organization), links to Organization for people, 
name fragments, and contact methods. 

Step5. The Remove entity module 1794 confirms the commit to the License 
Administrator. 

This use case has a number of extensions: 

° If there are any payments linked to the entity, the Remove entity 
module 1794 disallows removal and reports the error message " <Name> has one or 
more payments in the remove entity module 1794, so you cannot remove it." The 
<Name> is the name of the entity. 

" If there are any licenses linked to the entity, the Remove entity module 
1794 disallows removal and reports the error message " <Name> has one or more 
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license agreements in the remove entity module 1794, so you cannot remove it." The 
<Name> is the name of the entity. 

If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Context-Sensitive Help use case. 

5 Query Entities 

The query entities use case 15402 is diagramed in FIG. 154. This use case is 
used by the Link Payment to Entity use case to supply an entity to that use case for 
linking to a hcense payment. The License Administt-ator (and potentially any User) 
10 queries a named entity from the Licensing Database 1204 based on any of the 

structured fields of the entity (name, description, and entity type). The query entities 
module 15404 displays the name, description, and entity type of the named entities 
that match the query conditions and allows the License Administrator to select some 
for further processing in a using use case. The operation of this use case is further 
15 described below. 

Step 1. The query entities module 15404 displays a query form with the 
name, description, and entity type fields available for specifying a query. 

Step 2. The License Administrator enters the search criteria. 

Step 3. The query entities module 1 5404 queries all the entities that meet die 
20 query criteria from the Licensing Database 1204. The query entities module 15404 

displays die entities, showing the name, description, and type. 

Step 4. The License Administrator selects one or more entities for use in the 
using use case. 

Asset Use Cases 

25 An asset is an intellectual property document (for example, patent, copyright, 

trademark, trade secret, etc.) or an intellectual asset (for example, know how). 
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According to the invention, assets are combined into asset packages, which may be 
standard (lists of assets), group (reference to an IPAM group, for example, described 
above), or descriptive (a text describing the assets with language from the license 
agreement). 

Preferably, a group as described above (sometimes herein refer to as an IPAM 
group) differs from an asset package. When the licensing system 1 102 is integrated 
with the IPAM server 214, it is possible to create a type of an asset package (the IPAM 
group type) that links to a group and that acquires all of the documents associated with 
that group. In an embodiment, changes to the contents of the group automatically 
affect the asset package (in other embodiments, changes to the contents of the group 
do not automatically affect the asset package). The asset package is said to be linked 
(where the hnk is said to be "active") or associated with the group. But the asset 
package itself is a separate object from that group. 

Linking the package to a license agreement preferably means that the license 
licenses all of the assets in the package to the licensee, unless the license agreement 
indicates otherwise. 

An asset view 3002 is displayed when the asset packages icon 1 4 1 6 is pressed 
(FIG. 30). The Asset View 3002 contains two panes. The first pane, called the asset 
packages pane 3004, displays a spreadsheet of asset packages, and the second pane, 
called the assets pane 3006, displays the assets in the asset package selected in the 
asset packages pane 3004. 

Selecting an asset package in the asset packages pane 3004 displays the assets 
in that package in the assets pane 3006. Double-clicking on an asset package in the 
asset packages pane 3004 displays the asset package modification dialog, while 
double-clicking on the asset in the asset pane 3006 displays the asset modification 
dialog. You can enter a new package or asset by double-clicking on an empty record 
or clicking on the New button. If no package is selected, you create the new asset 
independently of any package; otherwise, you create the asset in the selected package. 
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Clicking on a Find tool displays the Find Asset dialog (FIGS. 64A and 65, for 
example), which lets you enter search conditions to search for an asset. The find tool 
may be accessed in a number of ways, such as frx)m the tool bar or via the menu (see 
HG. 67). Entering search conditions into this dialog and clicking on Find Now 
displays the matching assets in the extended dialog. See HGS. 64B and 66. You can 
then double-click on the asset to display the modification dialog with all the details 
of the asset, or you can drag-and-drop or copy-and-paste the assets into a selected 
asset package. 

Enter Patent 

The enter patent use case 3 102 is diagramed in FIG. 3 1 . 

The enter patent use case 3102 enables a Data Entry Clerk to enter 
information for a patent (U.S. or foreign) asset. The patent can be packaged alone or 
with other assets into asset packages that can be licensed. 

The operation of the enter patent use case 3 1 02 is further described below: 

Step 1 , The Data Entry Clerk starts a transaction to enter a new patent asset 
by issuing an appropriate command. This can be done, for example, by selecting 
New, Patent from the menu bar 1406 (HG. 32). 

Step 2. The enter patent module 1730 displays a data entry form called an 
enter new patent dialog 3302 (FIG. 33) for input and generates an object identifier for 
the new asset. The enter new patent dialog 3302 has two tabs, a general tab 3304 and 
a optional tab 3306. 

Step 3. The Data Entry Clerk chooses from a list of publishing organizations 
and document kinds. For example, the Data Entry Clerk can press a down arrow key 
3308 (FIG. 33) to view a list of available publishing organizations 3402 (FIG. 34). 
The Data Entry Clerk can press another down arrow key 33 12 to view and choose 
from a list of different types of documents, such as utility patent, design patent, plant 
patent, SIR, provisional application, patent application, etc. 
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Step 4. The Data Entry Clerk enters data into the following fields in any 
order: Document Number, Long Display Name, Patent Type, and Filing Date. 
Optionally, the user can enter the following fields in any order: Description, Title, 
Filing Date. Issue Date, and Publication Date. See FIGS, 33 and 35. The Data Entry 
Clerk sets the Security Class from a list of available security classes with Write 
privilege for the user. 

Step 5. The Data Entry Clerk conimits the transaction by pressing a save 
button 3310 (FIG. 33). 

Step 6. The enter patent module 1730 creates an IP Document, a Document, 
and an object of the appropriate subclass for the patent type in the Core Database 
1208. The enter patent module 1730 marks the Document as an IP Document. 

This use case has a number of extensions: 

° If the Data Entry Clerk presses Fl or the equivalent, the application 
extends the use case with the Display Help use case. 

If the IPAM Server 2 14 and IPAM database 2 1 6 are available, the 
Licensing System 1 102 disallows entry of patent information via the enter patent 
module 1730. Essentially, the enter patent module 1730 cannot be accessed when the 
IPAM Server 214 and IPAM database 216 are available. Instead, all patent 
information is obtained from the IPAM Server 214 and ff AM database 216. 

Enter Trademark 

The enter trademark use case 3602 is diagramed in FIG. 36. 

The Data Entry Clerk enters information for a trademark asset, including the 
trademark classes and the kind of trademark (US Federal, State, WIPO, etc.). 

The operation of the enter trademark use case 3602 is further described below . 

Step 1. The Data Entry Clerk starts a transaction to enter a new trademark 
asset. This can be done in a number of ways, such as by selecting New, Trademark 
from the menu bar 1406 (FIG. 32). 
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Step 2. The enter trademark module 1732 displays a data entry form 3702 
(FIG. 37) for input of trademark information and generates an object identifier for the 
new asset. The data entry form 3702 has a general tab 3704, an optional tab 3706, 
and a classes tab 3708. 

Step 3. The Data Entry Clerk chooses from a hst 3802 of publishing 
organizations (FIG. 38) and document/trademark kinds (by pressing a down arrow 
key 3712 to display a list of document/trademark kinds, where such 
document/trademark kinds are any known types). 

Step 4. The Data Entry Clerk enters data into the following fields in any 
order: Doc Kind, Document Number, Long Display Name, and Filing Date. 
Optionally, the user can enter the following fields in any order: Description, Title, 
Filing Date, Issue Date, and Publication Date. The Data Entry Clerk enters a set of 
Trademark Classes from a hst of classes. The Data Entry Clerk sets the Security Class 
from a list of available security classes with Write privilege for the user. See FIGS. 
37-40. 

Step 5. The Data Entry Clerk commits the transaction by pressing a save 
button 3804. 

Step 6. The enter trademark module 1732 creates an DP Document, a 
Document, an object of class Trademark, and an association object relating the 
trademark to a series of Trademark Classes in the Licensing Database 1 204. The enter 
U"ademark module 1732 marks the Document as an IP Document. 

At any time, if the Data Entry Clerk presses Fl or the equivalent, the 
appUcation extends the use case with the Display Help use case. 

Enter Copyright 

The enter copyright use case 4 1 02 is diagramed in FIG. 4 1 . In this use case, 
the Data Entry Clerk enters basic information for a copyright asset. 

The operation of the enter copyright use case 4 1 02 is further described below: 
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Step 1. The Data Entry Clerk starts a transaction to enter a new copyright 
asset. This can be done in a number of ways, such as by selecting New, Copyright 
from the menu bar 1406 (HG. 32). 

Step 2. The enter copyright module 1734 displays a data entry form 4202 
5 (FIG. 42) for input and generates an object identifier for the new asset. The data entry 

form 4202 has a general tab 4206 and an optional tab 4208. 

Step 3. The Data Entry Clerk chooses from a list of publishing organizations 
and document kinds. See, for example, FIG. 43. 

Step 4. The Data Entry Clerk enters data into the following fields in any 
1 0 order: Document Number, Long Display Name, and Filing Date. Optionally, the user 

can enter the following fields in any order Description, Tide, Filing Date, Issue Date, 
and Publication Date. The Data Entry Clerk sets the Security Class from a list of 
available security classes with Write privilege for the user. See HGS. 42-44. 

Step 5. The Data Entry Clerk commits the transaction by pressing a save 
15 button 4204. 

Step 6. The enter copyright module 1734 creates an IP Document, a 
Document, and an object of class Copyright in the Licensing Database 1204. The 
enter copyright module 1734 marks the Document as an IP Document. 

At any time, if the Data Entry Clerk presses Fl or the equivalent, the 
20 application extends the use case with the Display Help use case. 

Enter Trade Secret 

The enter trade secret use case 4502 is diagramed in FIG. 45, According to 
this use case, the Data Entry Clerk enters information for a Trade Secret asset. 

The operation of the enter trade secret use case 4502 is further described 

25 below: 

Step 1. The Data Entry Clerk starts a transaction to enter a new trade secret 
asset using any procedure described herein. 
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Step 2. The enter trade secret module 1736 displays a data entry form for 
input and generates an object identifier for the new asset. 

Step 3. The Data Entry Clerk chooses fh)m a list of publishing organizations 
and document kinds. 

Step 4. The Data Entry Clerk enters data into the following fields in any 
order: Document Number, Long Display Name, and Filing Date. Optionally, the user 
can enter the following fields in any order Description, Title, Filing Date, Issue Date, 
and Publication Date. The Data Entry Clerk sets the Security Class from a list of 
available security classes with Write privilege for the user. 

Step 5. The Data Entry Clerk commits the transaction. 

Step 6. The enter trade secret module 1736 creates an IP Document, a 
Document, and an object of class Trade Secret in the Licensing Database 1204. The 
enter trade secret module 1736 marks the Document as a type of know how. 

As always, at any time, if the Data Entry Clerk presses Fl or the equivalent, 
the application extends the use case with the Display Context-Sensitive Help use case. 

Enter Know How 

The enter know how use case 4602 is diagramed in FIG. 46. In this use case, 
the Data Entry Clerk enters information for a Know-How asset into the Licensing 
Database 1204. 

The operation of this use case is further described below: 

Step L The Data Entry Clerk starts a transaction to enter a new know how 
asset. This can be done in a number of ways, such as by selecting New, Know How 
from the menu bar 1406 (FIG. 32). 

Step 2. The enter know how module 1738 displays a data entry form 4702 
(FIG. 223) for input and generates an object identifier for the new asset. 

Step 3. The Data Entry Clerk enters various items: 
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Step3.1. The Data Entry Clerk sets the Description of the know 
how by entering text. The Data Entry Clerk can also link this asset to one or more 
other objects (such as documents, figures, software programs, etc.) that represent or 
illustrate the know how asset. 

Step 3.2. The Data Entry Clerk chooses from a list of 
intellectual asset kinds. This list can include any standard or use defined terms 
describing intellectual asset kinds, and could be based on technology area, market 
area, industrial area, corporate organization level, etc. 

Step 3.3. The Data Entiy Clerk sets the Security Class from a 
list of available security classes with Write privilege for the user. The security class 
indicates the users who have access to this record. 

Step 4. The Data Entry Clerk commits the transaction. 

Step 5. The enter know how module 1 738 creates a Document and an object 
of class Know How in the Licensing Database 1204. The enter know how module 
1738 marks the Document as a Know How. 

At any time, if the Data Entry Clerk presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

Modify IP Asset 

The modify DP asset use case 4802 is diagramed in FIG. 48. According to this 
use case, the License Administrator queries an DP asset and modifies it. The operation 
of this use case is further described below. 

Step 1. The License Administrator begins the transaction to modify an IP 
asset using any of the techniques described herein. 

Step2. The modify IP asset module 1740 uses the Query Assets module 1742 
to display a set of assets and to allow the License Administrator to select one for 
modification. 
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Step 3. If the License Administrator has Write permission on the selected 
asset, the BP asset module 1740 displays a forni containing, for example, these fields 
for the asset document: Document Number. Tide, Long Display Name, Issue Date, 
Filing Date, Publication Date, Description, Asset Type ("Disc Switch"), Pubhshing 
Organization (Description froni Pub Organization class), and Doc Kind (Description 
from IP Doc Kind class). 

Step 4. The License Administrator modifies any of the fields in any order and 
signals the end of the transaction. 

Step 5 . The IP asset module 1 740 writes the changes to the licensing database 
1204 or the core database 1208 and confmns the commit to the License 
Administrator. 

There are a number of extensions of this use case: 

" If the asset is a patent from the IP AM database 2 1 6, the user cannot 
modify any of the asset details. 

If the asset is a patent (JPO_PATENT, EPO_PATENT, PCT, or 
PTO_PATENT classes), the extended fields include Assignee, Class, International 
Class, and Inventor. 

If the asset is a Trademark, the extended fields include Trademark 
Class Display Name and Description. 

° If the asset is a Know How, the extended fields include the lA Kind 
Description and the Know How Description. 

° If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

Asset Package Use Cases 

An asset package includes one or more IP assets. Use cases related to asset 
packages are described below. 



wo 00/11575 



-61- 



PCT/US99/19050 



Create IP Asset Package 

The create IP asset package use case 4902 is diagramed in FIG. 49. 
According to this use case, the License Administrator creates a named package of 
intellectual property (IP) assets in the Licensing Database 1204. All or part of this 
asset package (possibly along with one or more other asset packages) may then be 
licensed via a license agreement. An asset package can be generated in a number of 
ways: by querying the assets from the Licensing Database 1 204, by querying a group 
from the Core Database 1208, or by entering a textual definition of the assets. The 
operation of this use case is further described below. 

Step 1 . The License Administrator begins the transaction to create a new IP 
asset package. This can be done in a number of ways, such as by selecting New, 
Asset Package from the menu bar 1406 (FIG. 32). 

Step 2. The create IP asset package module 1744 displays an asset package 
dialog 5002 (FIG. 50). From, a pull down list 5004, the License Adminisurator 
chooses the type of asset package to create (Asset/Standard, Group, or Descriptive 
Package Type). The Asset/Standard type is an asset package containing any 
combination of assets selected by the user. The Group type is an asset package 
containing the assets included in one or more pre-existing groups. The Descriptive 
Package type is an asset package whose assets are indicated by way of a description, 
such as a textual description, an audio description, a multimedia description (the files 
for those media types may be linked to this record). 

Step 3. The create IP asset package module 1744 creates a new package with 
a new object identifier. 

Step4. The License Administrator enters a Name for the package. Optionally, 
and in any order, the License Administrator enters the Description and/or the capture 
period (Start and End timestamps). See FIG. 51 . 

If the Asset/Standard type is selected, then an asset/standard type dialog 5 102 
is displayed (FIG. 51). The asset/standard type dialog 5102 has a general tab 5 104, 
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assets tab 5106, and allocation tab 5108. The License Administrator can use the 
Query Assets module 1742 to query a set of asset documents from the Licensing 
Database 1204 for the package. The create IP asset package module 1744 links these 
documents to the new package. The new assets are listed in the assets tab 5 1 06 (FIG. 
5 52). 

If the Package Type is Asset/Standard or Group, the License Administrator 
can choose to allocate the assets within die package. The create IP asset package 
module 1744 displays a list of the assets in the package, and the License 
Administrator enters an Allocation Percent for each asset. See FIG. 53. The License 

1 0 Administrator can select an even distribution or a custom distribution, where relative 

percentages are entered by the License Administrator. These allocations affect the 
manner in which license fees will be attributed to the assets in a package. For 
example, suppose an asset package includes an Assetl having an allocation of 60%, 
and an Asset2 having an allocation of 40% (as shown in the example of HG. 53). In 

15 this case, 60% of any license revenue attributed to this asset package will be 

considered to have been generated by Assetl, and 40% of any license revenue 
attributed to this asset package will be considered to have been generated by Asset2. 

If the Group type is selected, a group dialog 5402 is displayed (FIG. 54) 
having a general tab 5 104, a group tab 23004, and an allocation tab 5 108. The create 

20 IP asset package module 1744 displays a list of group names from the Core Database 

1 208, preferably in alphabetical order. The License Administrator as a User must have 
the ability to read the groups in the list. The License Administrator selects one or 
more groups that hold the documents/assets that the package is to package. The create 
IP asset package module 1744 displays the group documents and links them to the 

25 package in the group tab 5404 (FIG. 55). 

If the Descriptive type is selected, then a descriptive dialog 5602 is displayed 
(FIG. 56) having a general tab 5104 and a description tab 5604. The License 
Administrator enters text regarding Inclusion Criteria that describes the legal qualities 
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of the assets, preferably in the language from the Licensing Agreement, in addition 
to the Standard behavior. See FIG. 57. 

Step 5. The create IP asset package module 1744 writes the new asset 
package to the Licensing Database 1204, making the License Administrator user the 
owner of the package, then confirms the transaction commit to the License 
Administrator. 

Modify IP Asset Package 

The modify IP asset package use case 5802 is diagramed in FIG. 58. 
According to this use case, the License Administrator selects an IP Asset Package 
from the Licensing Database 1204, then modifies the information about the package 
and/or its contents: the documents listed in a standard package, the group contained 
within a Group package, or the text contained within a Descriptive package. The 
operation of this use case is further described below. 

Step 1. The License Administrator starts the transaction to edit an IP asset 
package. This can be done, for example, by selecting the asset packages icon 1416 
to display an asset package view 5902. The asset package view 5902 has a package 
list pane 5904 where asset packages are listed, and an asset Ust pane 5906 where 
assets in a selected asset package (selected in the package list pane 5904) are listed. 

Step 2. The modify IP asset package module 1 746 displays the asset packages 
in the packages list pane 5904 by querying the Licensing Database 1204, preferably 
displaying the Name, Description, and/or Package Type preferably in alphabetical 
order by name. The modify IP asset package module 1746 displays only those 
packages for which the License Administrator has Read permission or ownership. 

Step 3. The License Administrator selects a package in the packages list pane 

5904. 

Step 4. If the License Administrator has Write permission on the selected 
package or owns it, the modify IP asset package module 1746 displays a form 
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showing all the fields of the package, including the object identifier, the Package 
Name, the Description, the capture period (Start and End date/time), and the Package 
Type. This is similar to the examples shown in HGS. 50-57. 

Step 5. The License Administrator changes the Name, Description, Capture 
5 Period, Package Type, or other information in any order, then ends the transaction. 

Step 6. The modify IP asset package module 1746 updates the Licensing 
Database 1204 with the changes and confmns the commit to the License 
Administrator. 

This use case has a number of extensions: 
10 ^ If the License Administrator changes Package Type, the modify IP 

asset package module 1 746 uses the same logic as in the Create IP Asset Package use 
case 4902 to create a new subclass for the package with the appropriate contents. The 
modify IP asset package module 1746 removes any asset allocation percenls. The 
modify IP asset package module 1746 can undo the change until the License 
1 5 Administrator ends the transaction. 

° If the Package is a Standard package, the modify IP asset package 
module 1746 displays a Ust of assets. The License Administrator can add or remove 
assets from the list. The License Administrator uses the Query Assets use case to 
query a set of additional asset documents from the Core Database 1208 for the 
20 package. The modify IP asset package module 1746 links these documents to the new 

package. The License Administrator selects and removes asset documents. The 
License Administrator adjusts the Allocation Percent of each asset as required. 

° If the Package is a Group package, the modify IP asset package 
module 1746 displays the Name and Description of the group. The License 
25 Administrator can change the group by selecting from a list of available groups 

(groups from the Core database 1208 that the user has at least read access to, see the 
query in the Create IP Asset Package use case). The modify IP asset package module 
1746 displays a list of group names from the Core Database 1208 in alphabetical 
order. The License Administrator as a User must have the ability to read the groups 
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in the list. The License Adniinistrator selects a group that holds the documents that 
the package packages. The modify IP asset package module 1746 displays the group 
documents and links them to the package. The modify IP asset package module 1 746 
removes current Allocation Percent values (all links get deleted). 

If the Package is a Descriptive package, the modify BP asset package 
module 1746 displays the Description. The License Administrator can change the 
Description by editing the text. 

° If the License Administrator wants to modify the allocation of assets 
within the package, the modify ff asset package module 1746 displays the current 
allocations and the Administrator changes them.. 

Print Asset Package 

The print asset package use case 6002 is diagramed in FIG. 60. This use case 
extends the Print Object use case, and the Print License use case uses it. The print 
asset package module 1710 prints an Asset Package, including all information in the 
Licensing Database 1204 and the Core Database 1208 about the package and its 
documents. The operation of the print asset package module 1 7 1 0 is further described 
below. 

Step L The Actor in the Print Object use case or the Print License Use case 
selects an Asset Package and prints it. 

Step 2. The print asset package module 17 10 prints a formatted report with 
the Start Date, End Date, Name, Description, Package Type, etc. It then prints 
package-specific information (see Extensions). 

Step 3. The print asset package module 1710 prints the Document IDs of the 
documents and the document-specific information (see Extensions). 

This use case has a number of extensions: 
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If the package is a Descriptive Asset Package, the print asset package 
module 1710 prints the Inclusion Criteria for the package and does not print any 
documents. 

If the package is a Group Asset Package, the print asset package 
module 1710 prints the Group ID, Name, and Description of the group and prints the 
IP Documents and UDDs in the group. 

° If the package is a Standard Package, the print asset package module 
1710 prints the Documents in the package. 

° If a Document is an ff Document, the print asset package module 
1710 prints the Publishing Organization Description, the IP Doc Kind Description, 
the Document Number, the Title, and the Description. 

° If a Document is a Know-How, the print asset package module 1710 
prints the Intellectual Asset Kind Description and the Description. 

If a Document is a User Defined Document (UDD). the print asset 
package module 1710 prints information pertaining to the document. 

Remove IP Asset 

The remove DP asset use case 6102 is diagramed in FIG. 61. This is 
preferably an administrator use case. According to this use case, the licensing system 
administrator removes an JP asset (an IP Document or a Know How document, for 
example) and its related data from the Licensing Database 1204 and Core Database 
1208. The operation of this use case is further described below: 

Step 1. The System administrator begins the transaction. 

Step 2. The remove IP asset module 1703 displays a list of all assets (the IP 
Documents and Know How Documents) in the Licensing Database 1204 and Core 
Database 1208, displaying the Document ID, the Document Type (disc_switch for IP 
Documents and IA_Kind Description for Know How), the Document Number and 
Title for IP Documents, ordering by the type and document ID. 
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Step 3. The Administrator selects one or more assets and removes them.. 

Step 4. The remove IP asset module 1703 deletes the information from the 
Licensing and Core databases 1204 and 1208 and moves it to the Recycle Bin 
(unplementation may differ, deferring the actual SQL deletes, and there is no 
notification of commit to the Administrator). 

This use case has a number of extensions: 

At any time until clearing the Recycle Bin, the administrator can 
restore the removed Asset. 

** If the system integrates with the IP AM Server 2 14, the Administrator 
sees only assets fh)m the Licensing Database 1204, not those from the Core 1208 
(JPO_Patent, EPO_Patent, PCT, and PTO_Patent). The deletes from the 
IP_Document and Document classes are done with Administrator privileges in the 
Core database 1208 but do not affect patents in any way. 

** If the Administrator presses Fl or the equivalent, the apphcation 
extends the use case with the Display Help use case. 

Remove IP Asset Package 

The remove IP asset package use case 6202 is diagramed in HG. 62, 
According to this use case, the License Administrator selects an asset package from 
a list and removes it from the Licensing Database 1 204, subject to security access and 
links to license agreements. The operation of this use case is further described below. 

Step 1. The License Administrator begins a transaction. 

Step 2. The remove IP asset package module 1 748 displays a list of the asset 
packages to which the user has Read access or which the user owns, displaying the 
object identifier, the Name, the Description, and the Package Type, ordered by Name. 

Step 3. The License Administrator selects one or more asset packages to 
which the user has Delete access or which the user owns and removes them. The 
License Administrator then commits the transaction. 
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Step 4. The remove IP asset package module 1748 removes the persistent 
asset packages from the Licensing Database 1204 and confirms the operation to the 
License Administrator. The remove IP asset package module 1748 propagates the 
delete to the appropriate subclass based on Package_Type (Standard Asset Package, 
5 Descriptive Asset Package, Group Asset Package) and to the Secure Object 

superclass. 

This use case has a number of extensions. 

° If the asset package has links to a license agreement, the remove IP 
asset package module 1748 does not allow removal, displaying the error message 
10 "The <oid> license agreement uses this asset package; you cannot remove it." The 

<oid> is the object identifier for the license agreement. 

If the Data Entry Clerk presses Fl or the equivalent, the application 
extends the use case with the Display Context-Sensitive Help use case. 



Query Assets 

15 The query assets use case 6302 is diagramed in FIG. 63. This use case is used 

by other use cases. The License Administrator queries the Licensing Database 1204 
for a set of asset documents by entering search criteria into a form (see HGS. 64-66, 
for example). The License Administrator can remove assets from this set individually. 
The use case returns a set of License object identifiers (OIDs). The operation of this 

20 use case is further described below. 

Step 1. The using use case calls this use case, and the query assets module 
1742 displays, for example, a screen that contains these fields for search criteria: 
Document Number, Title, Long Display Name, Issue Date, Filing Date, Publication 
Date, Description, Asset Type ("Disc Switch"), Publishing Organization (Description 

25 fix)m Pub Organization class). Doc Kind (Description from IP Doc Kind class), and/or 

any other search fields discussed herein, or conventionally used. See example 
displays in FIGS. 64A, 64B, and 65. 
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Step 2. The License Administrator enters one or more fields of search criteria 
and submits the query. 

Step 3. The query assets module 1742 displays a list of documents 6602 that 
satisfy the query, displaying the Asset Type, Document Number, and Tide (for IP 
documents) and/or lA Kind and Description (for Know How), and to which the 
License Administrator has READ access. See FIGS. 64B and 66. 

Step 4. The license Administrator may take any number of actions, including 
one of these actions: 

Step 4.1. The License Administrator may select an asset for 
editing (Modify IP Asset use case). 

Step 4.2. The License Administrator may drag and drop or copy 
and paste an asset into a list of assets (Create or Modify IP Asset Package). 

Step 5. The License Administrator ends the use case. 

This use case has a number of extensions: 

If the asset is a patent (JPO_PATENT, EPO_PATENT, PCT, or 
PTO_PATENT classes), the extended search criteria includes Assignee, Class, 
Intemational Class, and Inventor. 

° If the asset is a Trademark, the extended search criteria includes 
Trademark Class Display Name and Description and the Trademark Kind 
Description. 

° If the asset is a Know How or Trade Secret, the extended search 
criteria includes the lA Kind Description and the Know How Description. 

° If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

Query Asset Packages 

The query asset packages use case 15902 is diagramed in FIG. 159. 
According to this use case, the Auditor, the Data Entry Clerk, or the License 



wo 00/11575 PCT/US99/19050 

-70- 



Administrator (and potentially any actor) queries an asset package from the Licensing 
Database 1204 based on any of the structured fields of die package (including 
inclusion criteria for descriptive asset packages and group name and description for 
group packages) or the list of assets (documents) associated with the package. The 
query asset package module 33504 displays the set of asset packages that qualify 
given the search criteria. The Modify Asset Package use case extends this one, 
enabling the actor to modify a package found through the query. This use case is 
further described below. 

Step 1 . The Actor begins the transaction. 

Step 2. The query asset package module 1 5904 displays a form that allows the 
Actor to specify a set of search criteria for the query. The main part of the form 
contains these fields: 

* Start Date (date on which asset package becomes effective, start of 
availability of assets in the package) 

* End Date (date on which asset package terminates, end of 
availability of assets in the package usually due to patent expiration or similar asset 
loss) 

* As Of Date (a date that is potentially between the Start Date and 
End Date, allowing the actor to search for asset packages that are effective as of the 
date) 

* Package Name (the text name of the package) 

* Package Description (the text describing the nature of the package) 

* Package Type (Standard, Descriptive, or Asset), defaulting to 

Standard 

Step 3. The Actor enters any of the fields and tells the query asset package 
module 15904 to execute the query. 

Step 4, The query asset package module 1 5904 concatenates all the conditions 
with a logical AND, then queries the Licensing Database 1204 using the resulting 
search condition. The query asset package module 1 5904 then displays a list of all the 
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asset packages that satisfy the search condition. The query asset package module 
15904 displays the Package Name, Description, and Package Type. 

Step 5. The Actor ends the transaction. 

This use case has a number of extensions: 
5 If the Actor selects a Package Type of Standard or Descriptive, the 

query asset package module 15904 displays an additional form that allows the user 
to enter a search expression that specifies a logical conditional expression of ANDs, 
ORs, and NOTs (with parenthetical grouping) combining assets ((Asset 1 AND Asset 
2) OR Asset 3) which it gathers with die Query Assets use case. The query asset 
10 package module 15904 queries the Licensing Database to find those packages with 

the appropriate combination of assets. 

** If the Actor selects a Package Type of Descriptive, the query asset 

package module 1 5904 displays an additional form that allows the user to enter a text 
search on Inclusion Criteria. The query asset package module 15904 queries the 
1 5 Licensing Database to fmd those Descriptive packages that qualify. 

° If the Actor selects a Package Type of Group, the query asset package 
module 15904 displays an additional form that allows the user to enter a text search 
on Group Name and/or Group Description. As well, the query asset package module 
15904 displays a form for entering a search expression for grouped documents with 
20 AND, OR, and NOT relational operators as for Standard or Descriptive packages. The 

query asset package module 1 5904 queries the Licensing Database to find those group 
packages with the appropriate combination of assets. 

License Agreements Use Cases 

A Ucense agreement is a contract in which an entity, the licensor, licenses 
25 intellectual property to another entity, the licensee. There may be a plurality of 

licensors and/or Ucensees. In addition to a variety of contract clauses and the links to 
any number of asset packages, the license agreement in the context of the present 
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invention contains definitions of tiie parties to the agreement, compensation terms, 
territorial restrictions, field-of-use (market area) restrictions, and any other terms 
and/or clauses used in license agreements. 

A License Agreements View 6802 (FIG. 68) displays a spreadsheet pane of 
all the license agreements. Double-clicking on a license displays the agreement 
modification dialog 6902 (FIG. 69). This dialog 6902 displays five tabs. The General 
tab 6904 shown here contains the basic information about the agreement. The Asset 
Packages tab 6906 lists the asset packages that are the subject of the license and lets 
the License Administrator administer the list. The Terms tab 6908 lists the 
compensation terms of the license (fees, royalties, advances, minimum guarantees, 
and other). The License Administrator can modify these terms through that tab. The 
Royalty Statements tab 6910 and Payments tabs 6912 let the License Administrator 
see the linked statements and payments related to the license, but not modify them. 

Double-clicking on the empty row or on the new button in the hcense 
agreements view 6802 displays the license creation dialog 7202 (FIG. 72). This dialog 
is the same as the modification dialog but does not display the Statements and 
Payments tabs, as a new license has none. 

Selecting a Find tool in this view displays the Find Agreement dialog 7002 
(FIG. 70), which lets you enter search terms for agreements. Entering search 
conditions into this dialog 7002 and clicking on Find Now displays the matching 
agreements in the extended dialog 7 1 02 (HG . 7 1 ). You can then double-click on the 
agreement to display the modification dialog with all the details of the license. 

Enter License Agreement 

The enter license agreement use case 7302 is diagramed in FIG. 73. 
According to this use case, tiie Data Entry Clerk enters a license agreement into the 
Licensing Database 1204. Entering the agreement entails entering structured data 
(name, description, effective date, and so on). The Data Entry Clerk enters a set of 
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compensation terms that describe the fee and royalty structure of the agreement. The 
Data Entry Clerk also links the agreement to a set of asset packages representing the 
licensed IP assets and to the various parties to the agreement (licensor, licensees, 
attorneys, and so on). The operation of this use case is further described below. 

Step 1. The Data Entry Clerk begins the transaction. 

Step 2. The enter license agreement module 1750 generates a new object 
identifier for the license agreement and displays a data entry form 7202 for the new 
license. 

Step 3. The Data Entry Clerk enters data into the structured data fields of the 
license creation dialog 7202 and links other objects as required: 

Step 3.1. The Data Entry Clerk enters the structured fields of 
the agreement: the Agreement ID, the Title/Name, Description, Effective Date, 
Expiration Date, Exclusivity, Assignable, Transferable, Revocable, Confidential, 
Terminated, etc. 

Step 3.2. The Data Entry Clerk enters the structured fields of 
the license agreement: Perpetual, Inftingement Based (see Extensions), Can 
Sublicense, Annual Audit, Audit at Licensee Expense, Favored Nation, 
Improvements, Grant Back, Withholding Percentage, etc. 

Step3.3. ' The Data Entry Clerk uses the Link to Asset Packages 
use case to specify the set of asset packages for the license. These linked asset 
packages are displayed in the asset packages tab 6906. 

Step 3.4. The Data Entry Clerk uses the Enter Compensation 
Term use case to enter the compensation terms for the license. This step repeats until 
the clerk enters all the terms in the license agreement. These terms are displayed in 
the terms tab 6908. 

Step 3.5. The Data Entry Clerk uses the Link to Party use case 
to specify a party to the agreement. Required parties include one licensor and at least 
one licensee. You can also add other parties such as attorneys and other roles entered 
through the Add Role use case by the License System Administrator. This step repeats 
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until the clerk has Hnked all the parties to the agreement. This information is 
displayed in the Licensor and Licensee fields (FIG. 72). 

Step 3.6. The Data Entry Clerk selects the Security Class for the 
new document fk>m a list of available security classes, which control who has access 
5 to this license. 

Step 4. The Data Entry Clerk commits the transaction. 
Step 5. The enter license agreement module 1750 creates the License 
Agreement or Infringement Based Agreement in the Licensing Database 1204. The 
enter license agreement module 1750 confirms the commit to the Data Entry Clerk. 
10 This use case has a number of extensions: 

° If the correct asset package or packages don't exist, extend the use 
case with the Create IP Asset Package use case to create the appropriate package(s). 

If the correct entity does not exist, extend the use case with the Enter 
Entity use case to create the appropriate entity. 
15 ° If the Data Entry Clerk indicates that the license agreement is 

infringement based, create an Infr Based Agreement rather than a License Agreement 
and add the Infringement Release Granted flag and the Infringement Comment field 
to the data entry form. A license is infiingement based if it resulted or is somehow 
associated with or related to an allegation of infringement (whether or not an 
20 infringement suit was filed in court). An embodiment of the invention supports 

additional information that you track for infringement based license agreements. 

^ If the Data Entry Clerk presses Fl or the equivalent, the application 
extends the use case with the Display Help use case. 

link to Party 



25 



The link to party use case 7402 is diagramed in FIG. 74. According to this 
use case, a Data Entry Clerk selects an entity from a list and a role from another list. 
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The Licensing Database 1204 creates a link between the entity, the role, and the 
license agreement from the using use case. This use case is further described below. 

Step 1. The Data Entry Clerk starts the use case with an open transaction 
containing a license agreement that will link to the entity and role, passing in the 
5 object identifier for the license agreement. 

Step 2, The link to party module 1756 queries the Licensing database 1204 
and displays the names and descriptions of the entities and roles. 

Step 3. The Data Entry Clerk selects one entity from the entity list and one 
role fix^m the role list. 
10 Step 4. The Data Entry Clerk signals the end of the use case. 

Step 5. The Licensing Database 1204 creates a Party link using the License 
Agreement OID. the Entity OID, and the Role OID. 
This use case has a number of extensions. 

The user can cancel the use case at any time. The result will be that 
15 the license agreement is unchanged from its status before using the use case, with no 

additional Party links. 

If the Data Entry Clerk presses Fl or the equivalent, the application 
extends the use case with the Display Help use case. 

Link to Asset Package 

20 The link to asset package use case 7502 is diagramed in FIG. 75. According 

to this use case, a Data Entry Clerk selects one or more asset packages from a list. The 
link to asset package module 1 752 creates a link between the input license agreement 
and the selected asset packages. The Data Entry Clerk sets the territorial and 
field-of-use restrictions (and any other license details) on each asset package link. The 

25 Data Entry Clerk indicates whether the link is a cross license and/or has any further 

limitations, obligations, rights, etc. as part of this license. The link to asset package 
module 1752 is further described below. 
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Step 1. The Data Entry Clerk starts the use case with an open transaction 
containing a license agreement that will link to the asset packages. The extended use 
case supplies the object identifier for the agreement. 

Step 2. The link to asset package module 1752 displays the names and 
descriptions of the asset packages in a list ordered by name. 

Step 3. The Data Entry Clerk selects one or more packages from the list. 

Step 4. The link to asset package module 1752 creates and displays a link 
between the Ucense agreement and each package the Data Entry Clerk selects and 
assigns default territorial and field-of-use values. The link to asset package module 
1752 sets the default Cross-Licensed flag to false. 

Step 5. The Data Entry Clerk adds territorial and field-of-use restrictions to 
the links using lists of the available territories and fields of use from the Licensing 
Database 1204. The Data Entry Clerk also sets the Cross-License flag to true if the 
particular package represents assets licensed by the licensee to the licensor instead of 
vice versa. The Data Entry Clerk removes unwanted territorial and field-of-use 
lestrictions from the links. The Data Entry Clerk enters any additional limitations in 
the Limitations field. All of these actions may occur in any order. The Data Entry 
Clerk signals the end of the use case. 

Step 6, The Licensing Database 1204 links the asset packages and the input 
license agreement and adds links to the required territories and fields of use for each 
link. 

This use case has a number of extensions: 

° The user can cancel the use case at any time. The result will be that 
the license agreement is unchanged from its status before using the use case. 

° If the Data Entry Clerk presses Fl or the equivalent, the application 
extends the use case with the Display Help use case. 
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- Enter Compensation Term 

The enter compensation term use case 7602 is diagramed in FIG. 76. 

The Enter License Agreement and Modify License Agreement use cases use 
this one to enter compensation terms to a license agreement in the Licensing Database 
1 204. The Licensing Administrator or Data Entry Clerk creates a licensing term with 
the details appropriate to the particular term. All terms have a description, an amount, 
and late payment penalties, and perhaps other attributes. Ongoing royalties have a 
time period and possibly tables of escalating amounts based on number of units/sales 
plus tables of estimated number of units/sales. Ongoing royalties break down into 
royalties on units sold, on revenue, or on revenue from sublicense royalties. A 
minimum guarantee also has a time period and possible escalations. An advance has 
a due date and may be refundable or not. A fee may be ongoing with a time period or 
a lump sum fee with a due date. 

The operation of this use case is further described below. 

Step 1. The using use case passes in the object identifier for the license 
agreement to which the Data Entry Clerk or License Administrator (the Actor) wants 
to add compensation terms. 

Step 2. The enter compensation term module 1754 displays a list of the 
current set of compensation terms (if any) for this license, preferably in order of term 
number, displaying the term Description, the compounding period Description, the 
Amount with its currency symbol, the Late Payment Interest Rate (if any), and the 
Term Type. 

Step 3. The Actor creates a new term and selects one of the term types 
(Royalty Per Unit, Royalty Per Sales Amount, Royalty Per Royalty Amount, 
Minimum Guarantee, Advance, Ongoing Fee, Lump Sum Fee, or Other). 

Step 4. The enter compensation term module 1754 displays the term witii 
default values (Amount 0, Currency from the last term or the default currency for the 
system, interest rate 0, fields for entering a Time Unit Period (see Extensions) with 



wo 00/11575 



PCT/US99/19050 



-78- 

default Time Unit Type of Month, Term Type. Royalty_Per_Sales_Amount). The 
enter compensation term module 1754 displays a form for the term given the default 
term type (see Extensions). It displays a choice of several period types and entry fields 
that differ depending on the period type the user chooses. 

Step 5. The Actor enters the standard details for the term and the details for 
the particular term type (see Extensions), then either repeats from step 3 or ends the 
use case. 

Step 6. The enter compensation term module 1 754 inserts the new terms into 
the Licensing Database 12404. The enter compensation term module 1754 extends 
the use case with the Create Expected Revenue use case, which computes the 
expected revenue amounts per period for the existing compensation terms. 

This use case has a number of extensions: 

° If the Actor presses Fl or the equivalent, the application extends the 
use case with the Display Help use case. 

° If the term type is Ongoing Royalty, the enter compensation term 
module 1754 displays fields for entering a Recurring Period (see below) and an 
ongoing royalty type (Per Unit, Per Sales, Per Royalty (Sublicense), default Per Sales. 

^ If the term type is Ongoing Royalty and the Royalty Type is Royalty 
Per Unit, the enter compensation term module 1754 displays fields for entering a 
Royalty Unit (default 'Unit'), the Estimated Number of Units per Period (default 0), 
a table for an escalation schedule (Starting Units, Ending Units, and Amount), and a 
table for Estimated Units (Period Number, Estimated Units). 

If the term type is Ongoing Royalty and the Royalty Type is Royalty 
Per Sales Amount, the enter compensation term module 1754 displays fields for 
entering the Percentage, the Net flag (default Tme), the Estimated Revenue Per Period 
(default 0), a table for an escalation schedule (Starting Amount, Ending Amount, and 
Royalty Percentage), and a table for Estimated Revenue (Period Number, Estimated 
Revenue). 
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° If the term type is Ongoing Royalty and the Royalty Type is Royalty 
Per Royalty Amount, the enter compensation temi module 1754 displays the same 
fields as for Royalty Per Sales Amount. 

If the Term Type is Minimum Guarantee, the enter compensation 
term module 1754 displays fields for entering a Time Unit Period (see below), a Due 
Date, and a table for an escalation schedule (Start Date, End Date, Amount). 

° If the Term Type is Advance, the enter compensation term module 
1754 displays the Due Date of the advance and the Refundable flag. 

° If the Term Type is Fee and the Fee Type is Ongoing Fee, the enter 
compensation term module 1 754 displays fields for entering a Time Unit Period (see 
below). 

If the Term Type is Fee and the Fee Type is Lump Sum, the enter 
compensation term module 1754 displays the Due Date. 

° If the Actor must enter a Recurring Period, the enter compensation 
term module 1754 displays the Time Unit Type, the Start Date, the Recurrence Rate, 
the Starting Interval, the Interval Unit Type, and the choice of ending the cycle with 
a specific number of recurrences (Recurring Period) or a specific End Date (End Date 
Period). 

Create Expected Revenue 

The create expected revenue use case 7702 is diagramed in HG. 77. This use 
case extends the Enter Compensation Term use case to build a series of expected 
future revenue payments. In other words, based on the compensation terms of the 
license agreement, it is possible for the invention to calculate expected revenue to be 
generated in the future by the license agreement. Such expected future revenue can 
then be compared to actual revenue. 
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The extending use case passes in the compensation term obj ect identifier. The 
create expected revenue module 1760 queries the compensation term and its 
components and generates the appropriate payments expected from that term. 

Operation of the create expected revenue module 1760 is further described 

below. 

Step 1 . The create expected revenue module 1 760 queries the Compensation 
Term in question from the Licensing Database 1204 to get the Amount and subtype 
of the term. 

Step 2. For each period that is part of the stmcture of the compensation term, 
the create expected revenue module 1760 creates an Expected License Revenue 
object in the Licensing Database 1204, giving it a payment number and a due date as 
well as the expected amount of the payment. 

Step 3. The create expected revenue module 1760 iterates through the 
expected revenues calculated in step 2 to subtract advance payment amounts from 
expected royalties and to reset Minimum Guarantees to the amount needed to bring 
the guarantee up to the guaranteed amount. 

This use case has a number of extensions: 

° For an Ongoing Royalty, the create expected revenue module 1760 
queries the time period, the scaling royalty structure, and the royalty type. 

° For a Royalty Per Unit, the Create expected revenue module 1760 
queries the Estimated Units Per Period and the set of period estimates. Using this 
information, die time period, and die scaling royalty structure, the Create expected 
revenue module 1760 computes the series of royalty payments due through the 
expiration of die license. The Description is "Per-unit royalty for die period from 
<start> to <end> at <Amount> <currency symbol> per <unit> [using scaled royalty 
from <starting units> to <ending units>]". The <start> and <end> are the computed 
period boundaries, the Amount is the term amount, the <currency symbol> is the term 
Unit Symbol, the <unit> is the Unit from the Ongoing Royalty, and the optional string 
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exists only for scaling royalties and lists the Starting Units and Ending Units from the 
Ongoing Royalty. 

° For a Royalty Per Sales Amount, the Create expected revenue module 
1 760 queries the Estimated Revenue Per Period and the set of period estimates. Using 
this information, the time period, and the scaling royalty structure, tiie Create 
expected revenue module 1760 computes the series of royalty payments due through 
the expiration of the license. The Description is "Revenue-based [sublicense] royalty 
for the period firom <start> to <end> at <Percentage> per <currency unit> of revenue 
[using scaled royalty from <starting units> to <ending units>]". The optional 
"subhcense" string appears when the object is a Royalty Per Royalty Amount. The 
<start> and <end> are the computed period boundaries, the Percentage is the Royalty 
Per Sales Amount Percentage, and the <currency unit> is the Unit Symbol for tiie 
term currency. The optional string exists only for scaling royalties and lists the 
Starting Units and Ending Units from the Ongoing Royalty. 

° For aMinimum Guarantee, the Create expected revenue module 1760 
queries the time period, the Due Date, and the scaling guarantee structure. Using this 
information, the Create expected revenue module 1760 computes the series of 
guarantee dates, setting the Expected Revenue Amount to the term Amount given the 
scaling table based on the Due Date. The Description is "Minimum Guarantee for 
period fix)m <start> to <end> using scaled guarantee for <Due Date>", where <stait> 
and <end> are the guarantee period boundaries and the <Due Date> is the Due Date 
of the actual scaling term used. 

° For an Advance, the Create expected revenue module 1760 queries 
the due date. The Create expected revenue module 1760 sets the Amount to the term 
amount and the Due Date to die term Due Date. The Description is "Advance on 
royalties due to be paid on <Due Date>". 

For a Fee, the Create expected revenue module 1760 queries the fee 

type. 
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° For an Ongoing Fee, the Create expected revenue module 1760 
queries the time period. Using this information, the Create expected revenue module 
1760 computes the series of fee payments due through the expiration of the license. 
The Amount is the term amount. The Description is "Ongoing fee for period from 
<start> to <end>", where <start> and <end> are the time period boundaries. 

° For a Lump Sum Fee, the Create expected revenue module 1 760 sets 
the Amount to the term amount and the Due Date to the Lump Sum Fee due date. The 
Description is "Lump-sum fee due on <Due Date>". 

° For Other Compensation, the Create expected revenue module 1 760 
queries the Description and Due Date and sets the Expected Revenue Amount to 0 
and the Due_Date to the Other Compensation Due Date. The Description is the term 
Description. 

Modify Compensation Term 

The modify compensation tenn use case 7802 is diagramed in HG. 78. The 
Modify License Agreement use case uses this one to change existing compensation 
terms that belong to a license agreement in the Licensing Database 1204. The 
Licensing Administrator selects a particular term and modifies its atuibutes. The 
operation of this use case is further described below. 

Step 1. The using use case passes in the object identifier for the license 
agreement in which the License Administrator wants to change compensation terms. 

Step 2. The modify compensation term module 1762 displays a list of the 
current set of compensation terms for this license in order of term number, displaying 
the term Description and the Term Type. 

Step 3. The License Administrator selects a term for modification. 

Step 4. The modify compensation term module 1762 displays the current 
values. It displays a data entry form for the term given the term type (see Extensions) 
that display the current values for the selected term. 



wo 00/11575 



-83- 



Step 5 . The License Administrator changes any of these values, then ends the 
use case. 

Step 6. The modify compensation term module 1 762 updates the term in the 
Licensing Database 1204. 

This use case has a number of extensions: 

° If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

If the term type is Ongoing Royalty, the Modify compensation term 
module 1762 displays fields for entering a Time Unit Period (see below) and an 
ongoing royalty type (Per Unit, Per Sales, Per Royalty (Sublicense), default Per Sales. 

° If the term type is Ongoing Royalty and the Royalty Type is Royalty 
Per Unit, the Modify compensation term module 1762 displays fields for entering a 
Royalty Unit (default 'Unit'), the Estimated Number of Units per Period (default 0), 
a table for an escalation schedule (Starting Units, Ending Units, and Amount), and a 
table for Estimated Units (Period Number, Estimated Units). 

" If the term type is Ongoing Royalty and the Royalty Type is Royalty 
Per Sales Amount, the Modify compensation temi module 1762 displays fields for 
entering the Percentage, the Net flag (default True), the Estimated Revenue Per Period 
(default 0), a table for an escalation schedule (Starting Amount, Ending Amount, and 
Royalty Percentage), and a table for Estimated Revenue (Period Number, Estimated 
Revenue). 

° If the term type is Ongoing Royalty and the Royalty Type is Royalty 
Per Royalty Amount, the Modify compensation term module 1 762 displays the same 
fields as for Royalty Per Sales Amount. 

If the Term Type is Minimum Guarantee, the Modify compensation 
term module 1762 displays fields for entering a Time Unit Period (see below), a Due 
Date, and a table for an escalation schedule (Start Date, End Date, Amount). 

° If the Term Type is Advance, the Modify compensation term module 
1762 displays the Due Date of the advance and the Refundable flag. 
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° If the Term Type is Fee and the Fee Type is Ongoing Fee, the Modify 
compensation term module 1762 displays fields for entering a Time Unit Period (see 
below). 

° If the Term Type is Fee and the Fee Type is Lump Sum, the Modify 
5 compensation term module 1762 displays the Due Date. 

If the License Administrator must enter a Time Unit Period, the 
Modify compensation term module 1 762 displays the Time Unit Type, the Start Date, 
the Recurrence Rate, the Starting Interval, the Interval Unit Type, and the choice of 
ending the cycle with a specific number of recurrences (Recurring Period) or a 
10 specific End Date (End Date Period). 

Remove Compemadon Term 

The remove compensation term use case 7902 is diagramed in HG. 79. The 
Modify License Agreement use case uses this one to remove existing compensation 
terms that belong to a license agreement in the Licensing Database 1204. The 
15 Licensing Administrator selects a particular term and removes it. The operation of 

this use case is further described below. 

Step 1. The using use case passes in the object identifier for the license 
agreement in which the License Administrator wants to change compensation terms. 

Step 2. The Remove compensation term module 1764 displays a list of the 
20 current set of compensation terms for this license in order of term number, displaying 

the term Description and the Term Type. 

Step 3. The License Administrator selects a term to remove. 

Step 4. The Remove compensation term module 1764 deletes the 
information kom the Licensing Database and moves it to the Recycle Bin 
25 (implementation may differ regarding deferring the actual SQL deletes, and there is 

no notification of commit to the Administrator). 
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Query License 

The query license use case 8002 is diagramed in FIG. 80. According to this 
use case, the Auditor, the Data Entry Clerk, or the License Administrator (and 
potentially any User) queries a license from the Licensing Database 1204 based on 
any of the structured fields of the license. The system displays the details of the 
license agreement, including a list of asset packages, the parties to the agreement, a 
Ust of compensation terms, a list of royalty statements, etc. The operation of this use 
case is further described below. 

Step 1. The Auditor starts the transaction. This can be accomplished in a 
number of ways, such as by selecting Tools, Find, License Agreement from the menu 
bar (nG.67). 

Step 2. The Query license module 1768 displays a query form 8 102 (FIG. 8 1 ) 
with any combination of the following structured fields available for query 
specification: object identifier. Agreement ID, Name, Title, Licensee, Licensor, 
Description, Effective Date, Exclusivity, Assignable, Transferable, Revocable, 
Confidential, Terminated, Expiration Date, Perpetual, Inftingement Based, Can 
Sublicense, Annual Audit, . Audit at Licensee Expense, Favored Nation, 
Improvements, Grant Back, Withholding Percentage, Asset Package Name, Field of 
Use, Territory, Party Name, etc. The example query form 25702 in FIG. 257 shows 
only a subset of these fields. 

Step 3. The Auditor enters the search criteria. 

Step 4. The Query license module 1768 queries all the licenses that meet the 
query criteria from the licensing database 1204 and for which the Auditor has Read 
access. The Query hcense module 1768 displays the licenses, preferably showing all 
of the fields in step 2 except for Party Name, Asset Package Name, Territory, and 
Field of Use, which are extensions. The Query license module 1768 orders the 
licenses by Agreement ID. 

Step 5. The Auditor ends the transaction. 
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This use case has a number of extensions: 

If the license agreement has any asset packages to which the Auditor 
has Read access or which the Auditor owns, the Query Hcense module 1768 displays 
the package name, whether the package is a cross-license package, and the 
Limitations field in a list ordered by name. If the Auditor selects a package, the Query 
license module 1768 extends the usecase with the Modify IP Asset Package use case. 

° If the license agreement/package combination has any territorial 
resuictions, the Query license module 1768 displays the territory's Abbreviation, Full 
Name, and Description in a hst ordered by Abbreviation. The Auditor cannot change 
territories here but must instead use the Modify License Agreement use case. 

° If the hcense agreement/package combination has any field-of-use 
restrictions, the Query license module 1768 displays the field-of-use Display Name 
and Description in a list ordered by name. The Auditor cannot change territories here 
but must instead use the Modify License Agreement use case. 

° If the license agreement has any parties, the Query license module 
1768 displays the entity name and role name of the parties in a list ordered by role 
name and entity name. If the Auditor selects a party, the Query license module 1768 
extends this use case with the Modify Entity use case. 

° If the license agreement has any compensation terms, the Query 
license module 1768 displays the term number, term type, and description in a list 
ordered by term number. If the Auditor selects a term, the Query license module 1 768 
extends this use case with the Modify Compensation Term use case. 

° If the license agreement has any royalty statements, the Query license 
module 1768 displays the royalty statement reporting period in a hst ordered by 
period. If the Auditor selects a statement, the Query hcense module 1768 extends this 
use case with the Modify Royalty Statement use case. 

If Infringement Based is Tme, the Query license module 1768 
displays the two Infr Based Agreement fields Infringement Release Granted and 
Infringement Comment. 
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° If the Auditor selects a queried license agreement row, the Query 
license module 1768 extends the use case with the Modify License Agreement use 
case. 

° If the Auditor presses Fl or the equivalent, the application extends the 
5 use case with the Display Help use case. 

Modify License Agreement 

The modify license agreement use case 8202 is diagramed in FIG. 82. 
According to this use case, the Data Entry Clerk modifies a license agreement in the 
Licensing database 1204. Modifying the agreement entails entering/revising 
10 structured data (name, description, effective date, and so on). The Data Entry Clerk 

can edit or add new compensation terms that describe the fee and royalty structure of 
the agreement. The Data Entry Clerk can revise the links between the agreement and 
the set of asset packages representing the licensed IP assets. The Data Entry Clerk 
can revise the links between the agreement and the set of entity roles that identify tiie 
15 various parties to the agreement (licensor, licensees, attorneys, and so on). This use 

case is further described below. 

Step 1 . The License Administrator begins the transaction. 

Step 2. The Modify license agreement module 1758 displays the License 
Agreements in the Licensing Database. 
20 Step 3. The License Administrator chooses a license agreement to modify. 

Step 4. If the License Administrator has write permission on the selected 
document, die Modify license agreement module 1758 displays the license agreement 
in a data entry form such as that used in the Enter License Agreement use case and 
shows the current values of all fields. See FIG. 69. 
25 Step 5. The License Administrator modifies any of the structured fields and 

linked objects of the license agreement in any order: 



wo 00/11575 



PCT/US99/19050 



-88- 



Step 5. 1 . The License Administrator modifies the structured 
fields of the agreement: the Agreement E), the Name, Description, Effective Date, 
Expiration Date, Exclusivity, Assignable, Transferable, Revocable, Confidential, and 
Terminated. 

5 Step 5.2. The License Administrator modifies the structured 

fields of the license agreement: Perpetual, Infiingement Based (see Extensions), Can 
Sublicense, Annual Audit, Audit at Licensee Expense, Favored Nation, 
Improvements, Grant Back, and Withholding Percentage. 

Step 5.3. The License Administrator uses the Link to Asset 
10 Packages use case to modify the set of asset packages for the license. 

Step 5.4. The License Administrator uses the Enter 
Compensation Term use case to create the compensation terms for the license. This 
step can be repeated. 

Step 5.5. The License Administrator uses the Remove 
1 5 Compensation Term use case to remove any unwanted compensation terms from the 

license to the Recycle Bin. This step can be repeated. 

Step 5 .6. The License Administrator uses the Link to Party use 
case to modify the set of parties to the agreement. Required parties include one 
. licensor and at least one licensee. You can also add other parties such as attorneys and 
20 other roles entered through the Add Role use case by the System Administrator. This 

step can be repeated. 

Step5.7. The License Administrator selects a different Security 
Class for the document from a list of available security classes. 

Step 6. The License Administrator commits the transaction. 
25 Step 7. The Modify license agreement module 1 758 updates the Agreement, 

License Agreement, and Infr Based Agreement objects in the Licensing Database 
1204 and confirms the commit to the License Administrator. 
This use case has a number of extensions: 
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° If the asset package or packages the License Administrator wants to 
add do not exist, extend the use case with the Create IP Asset Package use case to 
create the appropriate package(s). 

° If the correct entity the License Administrator wants to add does not 
exist, extend the use case with the Enter Entity use case to create the appropriate 
entity. 

If the License Administrator presses Fl or the equivalent, the 
apphcation extends the use case with the Display Help use case. 

Remove License Agreement 

The remove license agreement use case 8302 is diagramed in FIG. 83. This 
is preferably an administrator use case. According to this use case, the license system 
Administrator removes a Ucense agreement and its related data from the Licensing 
Database 1204, including infringement information, compensation terms, expected 
revenue, royalty statements, party links, asset package links, territorial restrictions, and 
field-of-use restrictions. The operation of this use case is described below. 

Step 1. The License system Administrator begins the transaction. 

Step 2. The Remove license agreement module 1 705 displays a list of all the 
hcenses in the Licensing Database, displaying the document ID, the Agreement ID, 
and the Name. 

Step 3. The License system Administrator selects one or more license 
agreements and removes them. 

Step 4. The Remove license agreement module 1705 uses the Remove 
Royalty Statement use case to remove the Royalty Statements with the agreements. 

Step 5 . The Remove license agreement module 1 705 deletes the information 
from the Licensing database 1204 and moves it to the Recycle Bin (implementation 
may differ regarding deferring the actual SQL deletes, and there is no notification of 
commit to the License system Administrator). 
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This use case has a number of extensions: 

At any time until clearing the Recycle Bin, the administrator can 
restore the removed License Agreement and its related information. 

° If the License system Administrator presses Fl or the equivalent, the 
5 application extends the use case with the Display Help use case. 

Print License 



The print license use case 8402 is diagramed in FIG. 84. Tiiis use case 
extends the Print Object use case. The System prints a License Agreement, including 
all information in the Licensing Database 1204 about the agreement, its parties, its 
1 0 compensation terms, its asset packages (with territorial and field-of-use restrictions), 

its royalty statements, and the expected revenue and payments received to date. The 
operation of this use case is further described below. 

Step I . The Actor in the Print Object use case selects a License Agreement 
and prints it. 

15 Step 2. The Print license module 1712 prints a formatted report with the 

Document ID, the Agreement ID, the Name, the Description, the Effective Date, the 
Expiration Date, and the various clause flags as check boxes. 

Step 3. The Print license module 1712 prints the parties to the agreement, 
with name, organization, and primary contact information. 

20 Step 4. The Print license module 1712 prints the compensation terms of the 

agreement, printing the Term Number, Term Type, and the Description of each term 
along with the currency symbol and the Amount and any Due Date for the term. 

Step 5. The Print license module 1712 prints the Asset Packages for the 
license using the Print Asset Package use case. 

25 Step 6. The Print license module 1712 prints the Royalty Statements received 

for the license using the Print Royalty Statement use case. 
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Step 7. The Print license module 1712 prints the Expected Revenues and the 
Payments linked to them, printing the Payment Number, Amount, and Due Date for 
each Revenue and the Payment BD, Receipt Date, Currency Unit Symbol, and 
Amount Allocated for each Payment. 

Administer Territories 

The administer territories use case 8502 is diagramed in HG. 85. This is 
preferably an administrator use case. According to this use case, the system 
Administrator creates, modifies, and/or removes territories from the Licensing 
Database 1 204. The system comes preinstalled widi the territories Worldv^ide, USA, 
Japan, and EU. The operation of this use case is further described below. 

Step 1. The System Administrator starts the transaction. 

Step 2. The Administer temtories module 1 709 displays a list of Territories, 
displaying the Territory ID, Abbreviation (such as EUS A), Full Name (such as East 
Coast of the United States of America), and Description (such as "the region 
including all eastern states of the United States of America"). 

Step 3. The System Administer takes one of the following actions: 

Step 3.1. The System Administrator creates a new Territory, 
entering the Abbreviation, Full Name, and Description (the Administer territories 
module 1709 generates the Territory ID). 

Step 3.2. The System Administrator selects one of the current 
Territories and modifies the Abbreviation, the Full Name, or the Description, 

Step 3.3, The System Administrator selects one of the current 
Territories and sets that territory to be the default. 

Step 3.4. The System Administrator selects one of the current 
Territories and removes it. 

Step 4. The System Administrator ends the transaction. 
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Step 5. The Administer territories module 1709 commits the changes in the 
Licensing Database 1204. The Administer territories module 1709 confirms the 
commit to the System Admmistrator. 

This use case has a number of extensions: 
5 If the System Administrator presses Fl or the equivalent, the 

application extends the use case with the Display Help use case. 

° If removing a territory, the Administer territories module 1 709 deletes 
the information from the Licensing database 1204 and moves it to the Recycle Bin 
(implementation may differ regarding deferring the actual SQL deletes, and there is 
10 no notification of commit to the System Administrator), The Administer territories 

module 1709 confirms the commit to the System Administrator. At any time until 
clearing the Recycle Bin, the administrator can restore the removed Territory and its 
related information. 



Administer Fields of Use 



15 The administer fields of use case 8602 is diagramed in FIG. 86. This is 

preferably an administrator use case. According to this use case, the system 
Administrator creates, modifies, and/or removes fields of use from the Licensing 
Database 1204. The operation of this use case is further described below. 
Step 1. The System Administrator starts the transaction. 
20 Step 2. The Administer fields of use module 1711 displays a list of Fields of 

Use, displaying the Field of Use ID, Display Name (for example, "semi")» and 
Description (for example, "semiconductor applications"). 

Step 3. The System Administer takes any of the following actions: 

Step 3.1. The System Administrator creates anew Field of Use, 
25 enteringtheDisplayNameandDescription(the Administerfieldsofusemoduie 171 1 

generates the Field of Use ID). 
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Step 3.2. The System Administrator selects one of the current 
Fields of Use and modifies the Display Name or the Description. 

Step 3.3. The System Administrator selects one of the current 
Fields of Use and sets it to be the default. 

Step 3.4. The System Administrator selects one of the current 
Fields of Use and removes it. 

Step 4. The System Administrator ends the transaction. 
Step 5. The Administer fields of use module 1711 commits the changes in the 
Licensing Database 1204. The Administer fields of use module 171 1 confiirms the 
commit to the System Administrator. 

This use case has a number of extensions: 

° If the System Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

If removing a Field of Use, the Administer fields of use module 1711 
deletes the information from the Licensing database 1 204 and moves it to the Recycle 
Bin (implementation may differ regarding details for deferring the actual SQL deletes, 
and there is no notification of commit to the System Administrator). The Administer 
fields of use module 1711 confirms the commit to the System Administrator. At any 
time until clearing the Recycle Bin, the administrator can restore the removed Field 
of Use and its related information. 

Display License Agreements 

The display license agreements use case 15302 is diagramed in FIG. 153. 
This use case displays a table of license agreements with the basic data for each 
agreement. The Actor may select one or more agreements and conduct further 
operations such as Modify License Agreement. The operation of this use case is 
further described below. 

Step 1 . The Actor starts the transaction. 
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Step 2. The display license agreements module 15304 displays a table of all 
the License Agreements to which the Actor has read access. Each row of the table 
corresponds to a License Agreement. The columns include the License Agreement ID, 
the Name, the Description, the Effective Date, the Expiration Date, the Withholding 
5 Percentage, and a series of checkbox items: Exclusivity. Assignable. Transferable, 

Revocable, Confidential, Terminated, Perpetual, Infringement Based, Can Sublicense. 
Annual Audit, Audit At Licensee Expense. Favored Nation, Improvements, and Grant 
Back. 

Step 3. The Actor ends the transaction. 

1 0 This use case has a number of extensions: 

° If the Actor wants to enter a new license, the Enter License 
Agreement use case extends this one in a separate transaction. When the extending 
use case ends, the display license agreements module 15304 displays the new license 
and its fields in the table. 

15 If the Actor wants to see or modify the details of the license 

agreement, the Modify Dcense Agreement use case extends this one in a separate 
transaction. The Actor selects a license agreement from the table and initiates the 
extending use case. The saved changes from the extending use case appear in the table 
when that use case ends. 

20 ** If the Actor wants to print a Ucense agreement, the Print License use 

case extends this one. The Actor selects one or more license agreements from the 
table and initiates the extending use case. 

° If the Actor is the License Administrator and wants to remove the 
selected licenses, the Remove License Agreement use case extends this one. The 

25 Actor selects one or more license agreement from the table and initiates the extending 

use case. When the extending use case returns, the display license agreements module 
15304 removes the selected license or hcenses from the table. 

Enter Adjustment 
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The enter adjustment use case 15702 is diagramed in FIG. 157. The Enter 
License Agreement and Modify License Agreement use cases use this one to enter 
adjustments to compensation terms in a hcense agreement in the Licensing Database 
1204. The Licensing Administrator or Data Entiy Clerk creates an adjustment with 
the details appropriate to the particular kind of adjustment. Adjustments have a 
description, an amount, a currency, and a due date. A minimum guarantee also has a 
time period and possible escalations. An advance may be refundable or not. 

The adjustments modify the revenue stream that compensation terms 
generate, and the Link Adjustment to Terms use case relates an adjustment to the 
terms that generate the revenue that it adjusts. 

It will be illustrative to consider selected background items. A license 
agreement structures its revenue stream based on a combination of fees and royalty 
payments (and possibly some other kinds of compensation). The agreement also 
contains terms that affect the revenue from these terms, the minimum guarantee and 
the advance. 

A minimum guarantee is an amount of money that the licensor must receive 
by the end of the guarantee period, usually one year but sometimes quarterly or some 
other period. If the revenue from certain compensation terms does not add up to this 
amount, the licensee must make up the difference. 

An advance is an amount paid to the licensor by the licensee in advance of 
revenue (usually royalties). The licensee then subtracts the advance amount from the 
compensation due until the entire amount of the advance is accounted for. From that 
point on, the hcensee then begins payments to the licensor. 

Any given adjustment may cover any number of different compensation terms 
for the same license. For example, an advance may cover an initial fee and a series of 
royalty payments. A minimum guarantee could cover two or three different royalty 
terms but not a maintenance fee. 

The operation of this use case is further described below. 
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Step 1. The using use case passes in the object identifier for the license 
agreement to which the Data Entry Clerk or License Administrator (the Actor) wants 
to add adjustments. 

Step 2. The enter adjustment module 15702 displays a list of the current set 
of adjustments for this license in preferably order of term number, displaying the 
Description, the Amount with its currency symbol, the Due Date, and the Adjustment 
Type. 

Step 3. The Actor creates a new adjustment and selects one of the term types 
(Minimum Guarantee or Advance). 

Step 4. The enter adjustment module 15702 displays the adjustment widi 
default values (Amount 0. Currency from the last term or the default currency for the 
system, and Due_Date empty). It displays a form for the term given the default term 
type (see Extensions). 

Step 5. The Actor enters the standard details for the adjustment and the details 
for the particular term type (see Extensions), then either repeats from step 3 or ends 
the use case. 

Step 6. The enter adjustoient module 15702 inserts the new terms into the ^ 
Licensing Database 1204. 

This use case has a number of extensions. 

° If the Actor presses Fl or the equivalent, the application extends the 
use case with the Display Help use case. 

° If the Term Type is Minimum Guarantee, the Actor uses the Enter 
Recurring Time Period use case to enter a Recurring Period (see below) or enters a 
Single Date. Optionally, the Actor enters a table for an escalation schedule (an Open 
Ended Period and an Amount for each row of the table). The enter adjustment module 
15702 inserts the items into the Minimum_Guarantee table and the 
Date_Amount_Interval table. 

° If the Term Type is Advance, the enter adjustment module 15702 
displays a field for entering a Single Date representing the due date of the advance and 
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a field for the Refundable flag. The enter adjustment module 1 5702 inserts these into 
the Advance table. 

If the Actor must enter a Recurring Period for a minimum guarantee, 
the enter adjustment module 15702 displays the Time Unit, the Start Date, the 
Recurrence Rate, the Starting Interval, the Interval Unit, and the choice of ending the 
cycle with a specific number of recurrences (Count Limited Recurring Period) or a 
specific End Date (Date Limited Recurring Period). 

Modify Adjustment 

The modify adjustment use case 16102 is diagramed in FIG. 161. The 
Modify License Agreement use case uses this one to change existing adjustments that 
belong to a hcense agreement in the Licensing Database 1204. The Licensing 
Administrator selects a particular adjustment and modifies its attributes. 

The Licensing Administrator also modifies the links between adjustments and 
compensation terms for the hcense agreement in the Link Adjustment to Terms use 
case. See the Enter Adjustment use case for background material on adjustments. 

The operation of this use case is further described below. 

Step 1. The using use case passes in the object identifier for the license 
agreement in which the License Administrator wants to change adjustments. 

Step 2. The modify adjustment module 1 6 104 displays a list of the current set 
of adjustments for this license in order of term number, displaying the term 
Description and the Term Type. 

Step 3. The License Administrator selects an adjustment for modification. 

Step 4. The modify adjustment module 16104 displays the current values for 
the selected adjustment through a data entry form for the adjustment, including due 
date, currency, amount, or description. 

Step 5. The License Administrator changes any of these values, then ends the 
use case. 
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Step 6. The modify adjustment module 16104 updates the adjustment in die 
Licensing Database 1204. 

If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case, 
5 ° If the Term Type is Minimum Guarantee, the modify adjustment 

module 1 6 1 04 displays fields for entering a Recurring Period (see below) and a table 
for an escalation schedule (an Open Ended Period and an Amount). The License 
Administrator may add or remove intervals from the escalation schedule or may 
change the amount or start date for an existing interval. 
10 ° If the Term Type is Advance, the modify adjustment module 1 6 1 04 

displays the Due Date of the advance and the Refundable flag. 

° If the Actor must enter a Recurring Period, the modify adjustment 
module 16104 displays the Time Unit, the Start Date, the Recurrence Rate, the 
Starting Interval, the Interval Unit, and the choice of ending the cycle with a specific 
1 5 number of recurrences (Count Limited Recurring Period) or a specific End Date (Date 

Limited Recuning Period). 

° If the modification to the adjustment affects the expected revenue for 
the license agreement, then all the expected Ucense revenues not linked to any 
payment and affected by the adjustment are removed and replaced with the changed 
20 values. 

Link to Adjustment 

The link to adjustment use case 16202 is diagramed in FIG. 162. According 
to this use case, a License Administrator selects one or more adjustments from a list. 
The link to adjustment module 16202 creates a hnk between the input compensation 
25 term and the selected adjustments. 
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It will be illustrative to consider selected background items. The invention 
allows one to adjust the revenue stream ftom a compensation term through advances 
or minimum guarantees. These are adjustment objects that are part of the hcense. 

The advance is a payment from the Ucensee to the licensor in anticipation of 
revenue fix)m the license. When the revenue comes due, the amount from the 
compensation terms covered by the advance is reduced by the amount of the advance 
until the revenue accounts for the entire advance. 

The minimum guarantee is a floor for revenue during a specific period, 
usually a year. If the revenue for that period does not come up to the guaranteed 
amount, the difference becomes due as a separate payment 

Advances and minimum guarantees may apply to only certain compensation 
terms associated with the license. Linking the compensation terms to the adjustments 
lets you specify exactiy how to adjust the revenue generated from the compensation 
terms in the Create Expected Revenue use case. 

The operation of this use case is ftirther described below. 

Step 1 . The License Administrator starts the use case with an open transaction 
containing a compensation term that will Unk to the adjustments. The extended use 
case supplies the object identifier for the agreement. 

Step 2. The link to adjustment module 16204 displays the types and 
descriptions of the adjustments for the license that owns the compensation term in a 
Ust ordered by adjustment number witiiin the license, displaying any existing links. 

Step 3. The License Administrator selects one or more adjustments from the 

list. 

Step 4. The adjustment module 16204 creates and displays a link for each 
adjustment the License Administrator selects. 

Step 5. The Licensing Database 1204 links the adjustments to the 
compensation term through the Tenn_Adjustment association table. 

This use case has a number of extensions. 
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° The License Administrator can cancel the use case at any time. The 

result will be that the compensation term is unchanged from its status before using the 
use case. 

° If the license Administrator presses Fl or die equivalent, the 

application extends the use case with the Display Help use case. 

° If the License Administrator selects an existing link from a 

compensation adjustment to a compensation term, he or she can delete die link. 

Remove Compensation Adjustment 

The remove compensation adjustment use case 16302 is diagramed in FIG. 
163. The Modify License Agreement use case uses this one to remove existing 
compensation adjustments tiiat belong to a hcense agreement in the Licensing 
Database 1204. The operation of this use case is further described below. 

Step 1. The using use case passes in the object identifier for the license 
agreement in which the License Administrator wants to change compensation 
adjustments. 

Step 2. The remove compensation adjustment module 16304 displays a list 
of the current set of compensation adjustments for this license in order of adjustment 
number, displaying the term Description and the Adjustment Type. 

Step 3. The License Administrator selects an adjustment to remove. In an 
embodiment, the adjustment cannot link to any compensation terms of the hcense. 

Step 4. The remove compensation adjustment module 16304 deletes the 
information from the Licensing Database 1204 and moves it to die Recycle Bin. 

Preferably, if die selected compensation adjustment has any compensation 
temi objects associated with it, the remove compensation adjustment module 16304 
refuses to remove the compensation adjustment and instead displays an error 
message, "Cannot remove this compensation adjustment because diere are links to 
compensation terms of tiiis license." 
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Royalty Statements Use Cases 

A royalty statement is a document that a licensee submits to a licensor to 
specify the licensed royalties owed for a given royalty period. A royalty statement 
includes a number of royalty statement details. Each royalty statement detail lists a 
5 product, a number of units sold, an amount of revenue, and a calculated royalty 

amount. 

The Royalty Statements View 8702 contains two panes, a license agreement 
spreadsheet 8704 and a royalty statement spreadsheet 8706. FIG. 87A. The 
agreement pane 8704 lets you select a license, and the royalty statement pane 8706 
10 displays the royalty statements for that license. You add and modify statements by 

double-clicking on a blank row or an existing row, as with all the other views. 

Enter Royalty Statement 

The enter royalty statement use case 8701 is diagramed in FIG. 87B. 
According to this use case, the Data Entry Clerk queries a license, then enters 
15 information about a royalty statement that appUes to that license into the database, 

then enters a series of detail items, one for each product detail on the royalty 
statement The new document has the classifier the Data Entry Clerk sets for it. The 
operation of this use case is further described below. 

Step 1. The Data Entry Clerk begins the transaction to enter a new royalty 
20 statement. The royalty statement view 8702 (FIG. 87 A) is displayed. 

Step 2. The Data Entry Clerk uses the Query License use case to identify and 
select the hcense to which the new royalty statement applies. Altematively, the Data 
Entry Clerk can select a license in the license agreement pane 8704 of the royalty 
statement view 8702. 

25 Step 3. The Enter royalty statement module 1 770 creates an object identifier 

for the new royalty statement that it uses to relate the statement to the queried license 
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agreement and to the statement details. It then Hnks the royalty statement to the 
queried license. 

Step 4. A royalty statement dialog 8802 (FIG, 88) is displayed. The royalty 
statement dialog 8802 has a general tab 8804 and a details tab 8806. In the general 
tab 8804, the Data Entry. Clerk enters the Fixed Time Interval for the 
reporting/statement period (Start Date and End Date) . The Data Entiy Clerk enters the 
royalty statement due date, receipt date, and (optionally) an investigation window date 
and a licensor invoice number. The Data Entry Clerk optionally sets a security 
classification from a list of available Write classifications from the BP AM Security 
Subsystem 1602, to indicate the persons who have access to this royalty statement 
record. 

Step 5. In the details tab 8806 (see FIG. 89), for each detail item on the 
royalty statement, the Data Entry Clerk creates a new detail for the royalty statement 
record by pressing the Add Detail button 8904. This results in displaying a detail 
dialog 9002. The Data Entry Clerk enters the product (selecting from a list of 
products associated with the licensee), the number of units sold of the product, the 
revenue received from the sale and the currency unit for the revenue, and the royalty 
due for the product, where this information is obtained from the royalty statement 
provided by the licensee. All details for the royalty statement are listed in a details 
area 8902 (FIG. 89). 

Step 6. The Data Entry Clerk commits the transaction. 

Step 7. The Enter royalty statement module 1770 inserts the Royalty 
Statement and its details into the licensing database 1 204 . The Enter royalty statement 
module 1770 requests the IPAM Security System 1602 to set the document 
classification. The enter royalty statement module 1 770 confirms the commit to the 
Data Entry Clerk. 

At any time, if the Data Entry Clerk presses Fl or the equivalent, the 
application extends the use case with the Display Context-Sensitive Help use case. 
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Modify Royalty Statement 

The modify royalty statement use case 9102 is diagramed in HG. 91. 
According to this use case, the License Administrator queries a license, then modifies 
any of the attributes of any of the linked royalty statements, and/or modifies any of the 
statement details, one for each product detail on the statement. The operation of this 
use case is further described below. 

Step 1. The License Administrator begins the transaction. 

Step 2. The Modify royalty statement module 1766 displays the licenses to 
which the License Administrator has read access, displaying the object identifier, the 
Agreement ID, the Name, and the Description, in a form similar to that shown in HG. 
87 A, 

Step 3. The License Administrator selects a license from the license pane 

8704. 

Step 4. The Modify royalty statement module 1 766 displays a list of existing 
royalty statements attached to the license in the royalty statement pane 8706. The 
Modify royalty statement module 1766 displays only those royalty statements to 
which the License Administrator has Read access. 

Step 5 . The License Administrator selects a royalty statement for modification 
from the royalty statement pane 8706. 

Step 6. If the License Administrator has Write access to the royalty statement, 
the Modify royalty statement module 1766 displays the current field values in a form 
similar to that shown in FIG. 88. 

Step 7 . The License Administrator may modify the royalty statement Invoice 
Number, Due Date, Receipt Date, or the Investigation Window Date in any order. 

Step 8. If the details tab 8806 is selected, the Modify royalty statement 
module 1766 displays the details for the selected royalty statement, displaying the 
product, the Units Sold, the Currency, and the Revenue. 
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Step 9. For each detail item on the royalty statement, the License 
Administrator can modify the name of the product, the number of units sold, or the 
revenue received and its currency unit, in any order. 

Step 10. The License Administrator commits the transaction. 

Step 11. The Modify royalty statement module 1766 updates the 
royalty statement. 

Step 12. If the License Administrator updated the time interval for the 
reporting period, the Modify royalty statement module 1766 creates a new time 
interval and adds the new period to the Licensing Database 1204 and removes the 
previous one if it is not linked to any other statements, making the relevant changes 
to the Time Period extent as well. 

Step 13. For each detail modified, the Modify royalty statement 
module 1766 updates the detail. 

Step 14. The Modify royalty statement module 1766 confirms the 
commit to the License Administrator. 

This use case has a number of extensions: 

° If the License Administrator wants to move the Royalty Statement to 
a different license, he or she drags the Royalty Statement to the license and drops it. 
The Modify royalty statement module 1766 changes the License ID in the Royalty 
Statement. 

° If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Context-Sensitive Help use case. 

Query Statement 

The query statement use case 9202 is diagramed in FIG. 92. According to this 
use case, the Auditor enters search criteria for the statement, and the Query statement 
module 1772 displays the statement from the Licensing Database 1204. The Auditor 
can select a statement to see the statement details, and he or she can select a detail to 
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see any payment allocations for the detail. The operation of this use case is further 
described below. 

Step 1. The Auditor starts the transaction. 

Step 2. The Query statement module 1772 displays the licenses to which the 
Auditor has read access, displaying the object identifier, the Agreement ID, the Name, 
and the Description in a format similar to that shown in FIG. 87 A. 

Step 3. The Auditor selects a license for query of statements. 

Step 4. The Query statement module 1772 displays a queiy form that lets the 
Auditor enter selection conditions on the set of statements, including object identifier, 
the reporting period Start and End Dates, the Invoice Number, the Due Date, the 
Receipt Date, and/or the Investigation Window Date. 

Step 5. The Auditor enters query criteria and starts the query. 

Step 6. The Query statement module 1 772 displays the royalty statements for 
the license in preferably reverse chronological order to which the Auditor has Read 
access, displaying the object identifier, the reporting period Start and End Dates, the 
Invoice Number, the Due Date, the Receipt Date, and the Investigation Window Date. 

Step 7. The Auditor selects a statement. 

Step 8. The Query statement module 1772 queries all the details of the 
selected royalty statement from the Licensing Database 1204 and displays them, if 
any, showing the Product, the Units Sold, the Revenue and its currency unit symbol, 
and the Royalty Due, in a form similar to that shown in FIG. 89. 

Step 9. The Auditor selects a detail. 

Step 10. The Query statement module 1772 queries all the payment detail 
allocations from the Licensing Database 1204 and displays the Amount Allocated for 
each one with a label that allows the Auditor to see it, if any. The Query statement 
module 1772 displays the Amount Allocated in the currency of the detail, converting 
it if the currency of the payment is different fix)m the detail currency unit using the 
Convert Currency use case. The Query statement module 1772 lists the allocations in 
preferably Receipt Date order. 
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Step 1 1 . The Auditor ends the transaction. 

Remove Royalty Statement 

The remove royalty statement use case 9302 is diagramed in FIG. 93. 
Preferably, this is an administrator use case. According to this use case, the system 
5 Administrator removes a linked royalty statement, which removes the statement 

details as well, all from the Licensing Database 1204. This operation is available only 
through the System Administrator interface to limit the potential for accidental 
removal of the data. The operation of this use case is fiirtiier described below. 
Step 1. The System Administrator begins the transaction. 
10 Step 2. The Remove royalty statement module 1 707 displays a list of existing 

royalty statements. 

Step 3. The System Administrator selects one or more royalty statements and 
removes them. 

Step 4. The Remove royalty statement module 1707 deletes the information 
15 from the licensing database 1204 moves it to the Recycle Bin (implementation may 

differ regarding details on deferring the actual SQL deletes, and there is no 
notification of commit to the System Administrator). 

This use case has a number of extensions: 

° If a using use case supplies a license object identifier, the use case 
20 shows only die royalty statements for that license (where License_Agreement_ID = 

:License_ID). 

° At any time until clearing the Recycle Bin, the administrator can 
restore the removed royalty statement. 

° If the System Administrator presses Fl or the equivalent, the 
25 application extends the use case with the Display Help use case. 



Prmt Statement 
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The print statement use case 9402 is diagramed in FIG. 94. This use case 
extends the Print Object use case, and the Print License use case uses it. The Query 
statement module 1772 prints a Royalty Statement, including all information in the 
Licensing Database 1204 about the statement, its details, and the allocation of 
payments to those details. This use case is further described below. 

Step 1 . The Actor in the Print Object use case or the Print License Use case 
selects a Royalty Statement and prints it. 

Step 2. The Print statement module 17 14 prints a formatted report with the 
Start Date, End Date, Agreement Name, Agreement ID, any Invoice Number, the Due 
Date, the Receipt Date, and/or the Investigation Window Date. 

Step3. The Print statement module 1714printstheRoyaltyStatement Details 
for the statement. Each detail contains the Product Name, Product Description, Units 
Sold, Revenue, Currency Unit Symbol, and/or Royalty Due. 

Step 4. For each detail, the Print statement module 1714 prints any payment 
allocations, printing the Payment ID, the Receipt Date, any Invoice Number, the 
Payor Name, the Amount Allocated, the Currency Unit Symbol, the Payment 
Amount, and/or the Payment Withheld Amount, preferably ordering the Ust by receipt 
date of the payment. 

Display Royalty Statements 

The display royalty statements use case 15802 is diagramed in FIG. 158. This 
use case displays a table of licenses and a table of royalty statements with the basic 
data for each agreement and statement within the agreement. The Actor may select 
an agreement. The display royalty statements module 15804 then displays all the 
royalty statements to which the Actor has read access that belong to the selected 
license agreement. The Actor may then select one or more statements within the 
agreement. 

The operation of this use case is further described below. 
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Step 1 . The Actor starts the transaction. 

Step 2. The display royalty statements module 15804 displays a table of all 
the License Agreements to which the Actor has read access using the Display License 
Agreements use case. 

5 Step 3. The Actor selects a single license agreement from that table. 

Step 4. The display royalty statements module 15804 displays a table of all 
the Royalty Statements from the Licensing Database 1 204 to which the Actor has read 
access. Each row of the table corresponds to a single Royalty Statement. The 
columns include the Reporting Period's Start Date and End Date, the Invoice Number, 
10 the Due Date, the Receipt Date, and the Investigation Window Date. 

Step 5. The Actor ends the transaction. 

° If the Actor wants to enter a new royalty statement, the Enter Royalty 
Statement use case extends this one in a separate transaction. When the extending use 
case ends, the System displays the new statement and its fields in the table. 

15 If the Actor wants to see or modify the details of the Royalty 

Statement, the Modify Royalty Statement use case extends this one in a separate 
transaction. The Actor selects a statement from the table and initiates the extending 
use case. The saved changes ftt)m the extending use case appear in the statement table 
when that use case ends. 

20 ° If the Actor wants to print a royalty statement, the Print Statement use 

Ccise extends this one. The Actor selects one or more royalty statements from the table 
and initiates the extending use case. 

° If the Actor is the License Administrator and wants to remove the 
selected statements, the Remove Royalty Statement use case extends this one. The 

25 Actor selects one or more royalty statements from the table and initiates the extending 

use case. When the extending use case returns, die display royalty statements module 
15804 removes the selected license or licenses from the table. 

Query Statement 
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The query statement use case 15502 is diagramed in FIG. 155. According to 
this use case, the Auditor enters search criteria for the statement, and the query 
statement module 15504 displays the statement from the Licensing Database 1204. 
The Auditor can select a statement to see the statement details, and he or she can 
5 select a detail to see any payment allocations for the detail. The operation of this use 

case is further described below. 

Step 1. The Auditor starts the transaction. 

Step 2. The query statement module 15504 displays the licenses using the 
Display Licenses use case. 
10 Step 3. The Auditor selects a license for query. 

Step 4. The query statement module 15504 displays a form that lets the 
Auditor enter any combination of the reporting period Start and End Dates, the 
Invoice Number, the Due Date, the Receipt Date, and the Investigation Window Date. 

Step 5. The Auditor enters values into the query form fields and starts the 

15 query. 

Step 6. The query statement module 15504 combines the entries into a 
complete query expression, executes the query in the Licensing Database 1204, then 
displays the resulting statements in the system that satisfy the query conditions to 
which the Auditor has read access, ordered by start date. 
20 Step 7. The Auditor selects a statement. 

Step 8. The query statement module 15504 queries all the details of the 
selected royalty statement from the Licensing Database 1204 and displays them in 
order of Line Number, if any, showing the Product, the Units Sold, the Revenue and 
its currency unit symbol, and the Royalty Due. 
25 Step 9. The Auditor selects a detail. 

Step 10. The query statement module 15504 queries all the payment detail 
allocations from the Licensing Database 1204 and displays the Amount Allocated for 
each one with a label that allows the Auditor to see it, if any. The query statement 
module 1 5504 displays the Amount Allocated in the currency of the detail, converting 
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it if the currency of the payment is different from the detail currency unit using the 
Convert Currency use case. The query statement module 15504 lists the allocations 
in preferably Receipt Date order. 

Step 1 1 . The Auditor ends the transaction. 

Payment Use Cases 

A payment is an amount of money the licensee sends to the licensor based on 
the amount they owe for fees, royalties, advances, minimum guarantees, and other 
compensation terms. To produce various reports, the License Administrator must link 
these payments to expected revenue periods and to royalty statement details. 

The Payments View 9502 contains two panes, a license agreement 
spreadsheet 9504 and apayment spreadsheet 9506. The agreement pane 9504 lets you 
select a license, and the payment pane 9506 displays the payments for that license. 
You add and modify payments by double-clicking on a blank row or as existing row, 
as with all the other views. 

Enter Payment 

The payment use case 10002 is diagramed in FIG. 100. According to this use 
case, the Data Entry Clerk records the details of a payment related to a license in the 
Licensing Database 1204. The operation of this use case is further described below. 

Step 1 . The Data Entry Clerk starts the transaction to enter a new payment. 

Step 2. The Enter payment module 1774 displays a list of licenses in the 
license pane 9504 of the payments view 9502. 

Step 3 . The Data Entry Clerk selects a license in the license pane 9504 of the 
payments view 9502. 

Step 4. The Enter payment module 1774 displays a list of payments for the 
license in the payments pane 9506. 
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Step 5 . The Data Entry Clerk signals the desire to add a new payment for the 
selected license using any procedure described herein. 

Step 6. The Enter payment module 1774 displays a form 9602 (FIG. 96) for 
entering the details of a payment and creates a new object identifier for the payment 
object and a link from that payment to the selected license. The form 9602 includes 
a general tab 9604, a royalty statement details tab 9606, and an expected revenue tab 
9608. 

Step 7. In the general lab 9604, the Data Entry Clerk enters the Receipt Date, 
the Amount received, and the Currency in any order. Optionally, the Data Entry Clerk 
enters a withheld amount (the part of the total amount of the payment that represents 
a foreign company's withholding of tax due on the payment), an invoice number (for 
an invoice needed to release the payment from a foreign tax authority), and any late 
payment interest amount (part of the total amount of the payment that is a penalty for 
late payment based on the interest rate in the license agreement), again in any order. 
The Data Entry Clerk selects a Security Class for the payment. The Data Entry Clerk 
commits the transaction. Data is not typically entered into the royalty statement 
details tab 9606 and the expected revenue tab 9608, although these tabs are active and 
accessible according to an embodiment of the invention. 

Step 8. The Enter payment module 1774 creates a persistent payment and a 
link to the indicated Ucense. The Enter payment module 1774 confirms the 
committed transaction to the Data Entry Clerk. 

At any time, if the Data Entry Clerk presses Fl or the equivalent, the 
apphcation extends the use case with the Display Help use case; 

Modify Payment 

The modify payment use case 10102 is diagramed in FIG. 101. According 
to this use case, the License Administrator modifies the details of a payment related 
to a Ucense. The License Administrator then optionally links the licensee's payment 
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to the expected revenue estimates of the license, to the details of a royalty statement, 
and to the general ledger debit and credit entries. The operation of this use case is 
further described below. 

Step 1. The License Administrator starts the transaction. 

Step 2. The Modify payment module 1 776 displays using the payments view 
9502 the licenses in the modify payment module 1776 to which the License 
Administrator has read access, displaying the object identifier, the Agreement ID, the 
Name, and the Description. 

Step 3. The License Administrator selects a license listed in the license 
agreement pane 9504. 

Step 4. The Modify payment module 1776 displays in the payments pane 
9506 the payments for the license to which the License Administrator has Read 
access, displaying the object identifier, the Payor Name, the Security Class, the 
Currency Symbol. The Amount, the Withheld Amount, the Late Payment Interest 
Amount, the Receipt Date, and/or the Invoice Number. 

Step5. TheLicense Administratorselectsapaymentfromthepayments pane 

9506. 

Step 6. If the License Administrator can write to the payment, the Modify 
payment module 1776 displays a form 9602 (HO. 96) for modifying the details of a 
payment, showing the fields from step 4 with their current values for the selected 
payment. 

Step 7. The License Administrator optionally modifies any of the fields 
except for the object identifier and commits the transaction. 

Step 8. The Modify payment module 1776 updates the payment in the 
Licensing Database 1204. The Modify payment module 1776 confirms the 
committed transaction to the Licensing AdminisU-ator. 

This use case has a number of extensions: 

° If the business is linking payments to expected license revenue 
estimates, the License Administrator uses the Link to Expected Revenue use case to 
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link the payment to the estimates. The license and payment object identifiers for the 
selected license and payment pass into the used use case. The used use case creates 
or removes any links in the Licensing Database. 

If the business is linking payments to royalty statement details, the 
License Administrator uses the Link to Detail use case to link the payment to the 
details of one or more royalty statement details. The license and payment object 
identifiers for the selected hcense and payment pass into the used use case. The used 
use case creates or removes any hnks in the Licensing Database. 

° If the business is recording GL entries, the License Administrator 
enters two General Ledger Entry items, supplying a GL Account Number from a list 
of valid numbers, an Amount, and an Entry Date (the date on which the GL recorded 
the payment) for each entry. The License Administrator chooses whether each entry 
is a debit or a credit entry.(These entries should usually be supplied by the accounting 
department, which then sends the records on to the licensing department for allocation 
purposes. The GL feature is optional and configurable.) The Modify payment module 
1776 creates a Debit General Ledger Entry or a Credit General Ledger Entry and a 
General Ledger Entry linked to the payment depending on the Entry Type. 

If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

Unk to Expected Revenue 

The link to expected revenue use case 10202 is diagramed in FIG. 102. 
According to this use case, a License Adminisuator allocates a payment to the 
expected revenue estimates deriving from the license compensation terms. The link 
to expected revenue use case 10202 creates a series of links to these estimates in the 
Licensing Database 1204. Via these links, it is possible to compare estimated license 
revenue to actual license revenue/payments. The operation of this use case is further 
described below. 
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Step 1 . The License Administrator initiates the use case from the calling use 
case, passing in an object identifier for a payment and an object identifier for a license 
agreement to which the payment apphes. 

Step 2. The link to expected revenue module 1778 displays in an estimate 
pane 9808 of the expected revenue tab 9608 (FIGS . 98 and 99) the Expected Amount, 
Due Date, and optionally a Description for each expected revenue estimate for the 
license. Note that there are estimates for each compensation term, and the 
compensation terms for the license agreement are listed in a term pane 9810. 

Step3. TheLicense Administratorselectsanestimateandentersan allocation 
amount for it. This can be done by entering an amount in field 9802, or a percentage 
of the total payment in field 9804. The total payment amount is displayed in field 
9806. This step repeats, as necessary. 

Step 4. The Link to expected revenue module 1778 stores an allocation 
amount into the Licensing Database 1204 for each non-zero allocation entered in step 
3. 

This use case has a number of extensions: 

If the License Administrator enters an allocation that violates the 
constraint on the set of allocations with respect to the total payment, the Link to 
expected revenue module 1778 displays the error message "Sum of allocations must 
be less than or equal to total payment" and clears the entered allocation. 

° If the License Administrator signals completion of linking and there 
are any nonpositive allocation amounts, the Link to expected revenue module 1778 
displays the error message "You must enter a positive allocation for each revenue 
estimate you select" and puts the focus on tiie first nonpositive amount in the list. 

° The currency unit of the payment should match tiie currency unit of 
tiie expected revenue estimate. If not, the Link to expected revenue module 1778 
displays a warning message ("Converting currencies from %s to %s") tiiat the 
amounts are in different currencies and offers the user the chance to use the Convert 



wo 00/11575 



PCT/US99/19050 



-115- 

Currency use case to convert one currency to the other. The link to expected revenue 
module 1778 displays both the amounts in each allocation link. 

If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

Unk to Detail 

The link to detail use case 10302 is diagramed in FIG. 103. This use case 
extends the Modify Payment use case. While modifying a payment, the Ucense 
Administrator selects one or more details ftx)m aroyalty statement. The use case links 
the selected details to the payment, allocating part of the payment to each of the 
details. The operation of this use case is further described below. 

Step 1 . The License Administrator initiates the use case from the calling use 
case, passing in an object identifier for a payment and an object identifier for a license 
agreement to which die payment applies. 

Step 2. The Link to detail module 1780 displays the royalty statements for the 
license in the royalty statement details tab 9606 (FIG, 96). In the example of HG. 97, 
there are two royalty statements 9710 and 9712 displayed. Royalty statement 9710 
has two details 9714, and royalty statement 9712 has two details 9716. In an 
embodiment, more complete information is displayed for each detail at this point. 
Such information may include the line number, product name, units sold, revenue 
amount, royalty due with currency symbol, etc. 

Step 3. The License Administrator selects a detail and enters an allocation 
amount. This can be done by entering an amount (such as in field 9704), or a 
percentage of the payment total (such as in field 9708). This step repeats as 
necessary. 

Step 4. The License Administrator signals completion. 
Step 5. The Link to detail module 1780 creates links between the details and 
the payment. 
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This use case includes a number of extensions: 

If the License Administrator enters an allocation that violates the 
constraint on the set of allocations with respect to the total payment, the Link to detail 
module 1780 displays the error message "Sum of allocations must be less than or 
5 equal to total payment" and clears the entered allocation. 

° If the License Administrator signals completion of linking and there 
are any nonpositive allocation amounts, the Link to detail module 1780 displays the 
error message "You must enter a positive allocation for each detail you select" and 
puts the focus on the first nonpositive amount in the list. 
1 0 ° The currency unit of the payment should match the currency unit of 

the statement detail. If not, the Link to detail module 1780 displays a warning 
message ("Converting currencies from %s to %s") that the amounts are in different 
currencies and offers the user the chance to use the Convert Currency use case to 
convert one currency to the other. The link to detail module 1780 displays both the 
1 5 amounts in each allocation link. 

If the License Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 



Print Payment 

The print payment use case 10402 is diagramed in FIG. 104. This use case 
20 extends the Print Object use case. The print payment module 1716 prints a Payment, 

including all information in the Licensing Database 1204 about the payment, its 
General Ledger entries, and its allocation to royalty statement details and to expected 
revenue. The operation of this use case is further described below. 

Step 1 . The Actor in the Print Object use case selects a Payment and issues 
25 a command to print it. 
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Step 2. The Print payment module 1716 prints a formatted report with the 
Payment BD, the Currency Unit Symbol, the Amount, the Withheld Amount, the Late 
Payment Interest Amount, the Receipt Date, the Invoice Number, etc. 

Step 3. The Print payment module 1716 prints the General Ledger Entries, 
printing the GL Account Number, the Account Description, the Amount, the Entry 
Date, and the Entry Type (credit or debit). 

Step4. The Print payment module 17 16 prints the allocations of the payment 
to royalty statement details, including the Royalty Statement Start and End Dates, the 
Detail Line Number, the Product Name, the Detail Currency Unit Symbol, Etetail 
Royalty Due, and the Amount Allocated. 

Step 5. The Print payment module 1716 prints the allocations of the payment 
to expected revenue, including the License Agreement ID and Name, the Term 
Number, the Expected Currency Unit, the Expected Amount, the Expected Due Date, 
and the Amount Allocated. 

Remove Payment 

The remove payment use case 10502 is diagramed in FIG. 105. This is 
preferably an administrator use case. According to this use case, the System 
Administrator removes payments and related GL Entries and license and detail 
allocations from the Licensing Database 1204. This use case is further described 
below. 

Step L The System Administrator begins the transaction. 

Step 2 . The Remove payment module 1713 displays a list of all the payments 
in the Licensing Database 1204, displaying the Payment ID, the Payor Name, the 
Receipt Date, and the Amount. 

Step3. The System Administrator selects one or more payments and removes 
them (that is, issues command(s) to remove them). 
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Step4. The Remove payment module 17 13 deletes the information from the 
Licensing database 1204 and moves it to the Recycle Bin (implementation may differ 
regarding deferring the actual SQL deletes, and there is no notification of commit to 
the System Administrator). 

This use case has a number of extensions: 

At any time until clearing the Recycle Bin, the administrator can 
restore the removed Asset. 

If the System Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 

Query Payment 

The query payment use case 10602 is diagramed in FIG. 106. According to 
this use case, the Auditor queries payments based on payer, on licensees or licensors, 
on links to royalty statements or expected revenue, on General Ledger accounts, or 
on receipt date. The Query payment module 1784 displays the payments, any links, 
and any GL entries. The operation of this use case is further described below. 

Step 1. The Auditor starts the transaction. 

Step 2. The Query payment module 1784 displays the licenses to which the 
Auditor has read access, displaying the object identifier, the Agreement ID, the Name, 
and the Description. 

Step 3. The Auditor selects a license for query of payments. 

Step 4. The Query payment module 1784 displays a query form that lets the 
Auditor enter selection conditions on the set of payments, including object identifier, 
Payor Name, payment Receipt Date, Amount, Withheld Amount, Late Payment 
Interest Amount, and/or Invoice Number. 

Step 5. The Auditor enters query criteria and starts the query. 

Step 6. The Query payment module 1784 displays the payments for the 
license in preferably reverse chronological order to which the Auditor has Read 
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access, displaying the object identifier, object identifier, Payor Name, payment 
Receipt Date. Amount. Withheld Amount, Late Payment Interest Amount, and/or 
Invoice Number. 

Step 7. The Auditor selects a payment. 
5 Step 8. The Query payment module 1784 displays a list of General Ledger 

entries, if any, showing the Entry Type. GL Account Number, Amount, Currency 
Unit Symbol, and Entry Date. The Query payment module 1784 preferably orders the 
entries by GL Account Number. 

Step 9. The Query payment module 1784 displays a list of Payment Detail 
10 Allocations, showing the Royalty Statement Start Date Time and Amount Allocated. 

The Query payment module 1784 preferably orders the allocations by License Name, 
Start Date Time, and Line Number. 

Step 10. The Query payment module 1784 displays a list of License 
Payment Allocations, showing the License Name, Payment Number. Expected 
15 License Revenue Description and Due Date, and Amount Allocated. The Query 

payment module 1784 preferably orders the allocations by License OID. Term 
Number, and Payment Number. 

Step 1 1 . The Auditor ends the transaction. 

At any time, if the Data Entry Clerk presses Fl or the equivalent, the 
20 application extends the use case with the Display Help use case. 

Maintain GL Accounts 

The maintain GL accounts use case 10702 is diagramed in FIG. 107. 
According to this use case, the License Administrator creates, updates, or removes 
accounts from the Licensing Database 1 204. The operation of this use case is further 
25 described below. 

Step 1. The License Administrator starts the transaction. 
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Step 2. The Maintain GL accounts module 1786 displays the list of current 
GL Accounts, displaying the Account Number and the Description. 

Step 3. The License Administrator modifies the set of GL Accounts, 
performing any of the following actions on the set of accounts: 
5 Step 3. 1 . The License Administrator creates a new GL Account, 

entering the Account Number and the Description. 

Step 3.2. The License Administrator selects one of the current 
GL Accounts and modifies the Account Number or the Description. 

Step 3 .3 . The License Administrator selects one of the current 
10 GL Accounts and removes it. 

Step 4. The License Administrator ends the transaction. 
Step 5. The Maintain GL accounts module 1 786 commits the changes in the 
Licensing Database 1204. The Maintain GL accounts module 1786 confirms the 
conmiit to the License Administrator. 
15 If a GL Account relates to any General Ledger Entries, on modifying the 

account number, the Maintain GL accounts module 1786 prompts the License 
Administrator whether to change the account number for the Entries or to cancel the 
transaction. 

Link Payment to Entity 

20 The link payment to entity use case 1 5 102 is diagramed in FIG. 151. This use 

case extends the Modify Payment use case to link or unlink the portion of a payment 
linked to a particular license to a specific set of named entities in the Licensing 
Database 1204. The License Administrator allocates some portion of the portion of 
a payment to a specific named entity. 

25 It will be illustrate to consider the following scenario. A licensor licenses 

packages of assets to licensees with a license agreement. The licensees use the assets 
to produce products that generate revenue. Depending on the license agreement 
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compensation terms, the licensee pays various kinds of payments to the licensor fees 
or royalties. These payments constitute a revenue stream to the licensor as a series of 
payments from the licensee. A single payment may encompass more than one license, 
so the link between payment and license has a percent allocation that allocates a 
specific percentage of the payment to a particular license. 

The licensor is usually an organization. Often, the licensor is not the business 
unit or person that ultimately "gets" or recognizes the revenue from a license for 
accounting purposes. That entity may be an organizational child of the licensor, but 
not necessarily, and there may be more than one entity that gets revenue from a 
license. A licensor therefore must have a way to allocate payment revenue from a 
particular license (a portion of a payment) to one or more named entities (people or 
organizations). 

The operation of this use case is further described below. 

Step 1. The link payment to entity module 15104 passes in the object 
identifier for a license agreement and a payment (a License Payment link). 

Step 2. The System displays the current set of links to entities from this 
license-payment link, displaying the name, description, and entity type for each linked 
entity. 

Step 3 . The License Administrator uses the Query Entities use case to display 
a list of entities. The License Administrator selects a single named entity from the 
result of the query and links it to the license-payment link. The Query Entity use case 
returns the object identifier for the entity to this use case. 

Step 4. The link payment to entity module 1 5 1 04 displays a form that lets the 
license administrator allocate a percentage of the license-payment amount to the 
entity. It displays a default value of 1(X)% if there are no license payment allocations 
for this license-payment link or the difference between the sum of existing hcense 
payment allocations for this license-payment link and 100% . 
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Step 5. The link payment to entity module 15 104 creates a link between the 
license-payment and the named entity, inserting a row in the License Payment 
Allocation table and displaying the new link in the displayed list of links. 

Step 6. The License Administrator repeats steps 3-6 or ends the use case and 
5 returns to the extending use case. 

If the License Administrator wants to remove a given link, he or she selects 
it in the displayed list of links and tells the System to delete the link. The System then 
removes the link from the display and schedules the link for deletion from the 
database (the extending use case is running the transaction). The License 
1 0 Administrator can remove or add any number of links in this use case. 

Display Payments 

The display payments use case 1 5202 is diagramed in FIG. 152. This use case 
displays a table of license agreements with the basic data for each agreement. The 
Actor may select one or more agreements and conduct further operations such as 
15 Modify License Agreement. The operation of this use case is further described 

below: 

Step 1 . The Actor starts the transaction. 

Step 2. The display payments module 15204 displays a table of all the 
License Agreements to which the Actor has read access using the Display License 
20 Agreements use case. 

Step 3. The Actor selects a single license agreement from that table. 

Step 4. The display payments module 15204 displays a table of all the 
Payments from the Licensing Database 1204 to which the Actor has read access. Each 
row of the table corresponds to a single Payment. The columns include the Payor 
25 Name, the Currency Unit Symbol, the Payment Amount, the Late Payment Interest 

Amount, the Receipt Date, the Invoice Number, and the Payment-to-License 
Allocation Percent. 
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Step 5. The Actor ends the transaction. 
This use case has a number of extensions: 

° If the Actor wants to enter a new payment, the Enter Payment use case 
extends this one in a separate transaction. When the extending use case ends, the 
display payments module 15204 displays the new payment and its fields in the table. 

° If the Actor wants to see or modify the details of the payment, the 
Modify Payment use case extends this one in a separate transaction. The Actor selects 
a payment fh)m the table and initiates the extending use case. The saved changes from 
the extending use case appear in the table when that use case ends. 

° If the Actor wants to print a payment, the Print Payment use case 
extends this one. The Actor selects one or more payments from the table and initiates 
the extending use case. 

° If the Actor is the License Administrator and wants to remove the 
selected payments, the Remove Payment use case extends this one. The Actor selects 
one or more payments fiom the table and initiates the extending use case. When the 
extending use case returns, the display payments module 15204 removes the selected 
payment or payments from the table. 

Time Period Use Cases 

The invention supports time period related structures. For example, Royalties 
and Fees often have a recurring payment. For example, a royalty may be due at the 
end of every quarter, on every June 15, or something similar. Most license royalties 
and fees call for monthly, quarterly, or annual payments. 

Generally, recurring periods may terminate in one of two ways. A 
count-limited period has a certain number of periodic payments. For example, you 
could have a yearly fee due on June 15th for five payments. A date-limited period 
goes to a certain end date: a royalty paid quarteriy on the 1 5th of the second month of 
the quarter ending on February 15, 2015. 
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The beginning interval from the start date to the first recurring date may differ 
significantly in size fix>m the other dates, as may the period from the last recurring 
date to an end date for a date-terminated period For example, you may owe an annual 
fee every June 15th. with the sequence starting on June 1 . The first interval will be 1 5 
5 days, while the second and onwards will be one year. 

In this section, time period use cases are described. 



Enter Recurring Time Period 

The enter recurring time period use case 15602 is diagramed in FIG. 156. 
1 0 This use case is used by other use cases that must enter a recuning period of some 

kind into tht Licensing Database 1204. The use case permits the actor to enter the 
repetition structure for the recurring period. The operation of this use case is fiirther 
described below. 

Step 1. The enter recuning time period module 15602 displays a data entry 
15 form containing the Time Unit (default Year), the Repetition (default 1), and the 

Recurring Period Type (default Count Limited). 

Step 2. The Actor chooses a Time Unit, a Repetition, and/or a Recurring 
Period Type. 

Step 3. The enter recurring time period module 1 5602 returns the appropriate 
20 object back to the using use case. The enter recurring time period module 1 5602 sets 

the Time Period's Time Period Type field to 'R' to indicate a recurring period object. 
This use case has a number of extensions. 

° Depending on the Time Unit, the enter recurring time period module 
15602 displays a set of options that the actor can use to control complex recurring 
25 stmctures. 

° If Time Unit is Year, the enter recurring time period module 1 5602 
displays the Yearly options and allows the actor to choose between two sets of 
options: 
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Specific Month and Specific Day: June 1 5th, November 2 
Ordinal Week of Month and Day of Week and Specific 

Month: first Tuesday in January 

° If Time Unit is Quarter, the enter recurring time period module 1 5602 
displays the Quarterly options and allows the actor to choose between three sets of 
options: 

Specific Day and Month: firstdayofsecondmonthof quarter 
Specific Day of Week and Month: first Monday in second 

month of quarter 

Specific Day: 45th day of quarter 
If Time Unit is Month, the enter recurring time period module 1 5602 
displays the Monthly options and allows the actor to choose between two sets of 
options: 

Specific Day: 15th, 21st 

Ordinal Week of Month and Day of Week: first Tuesday of 

the month 

If Time Unit is Week, the enter recurring time period module 1 5602 
displays the Weekly options and allows the actor to enter the day of the week: 
Tuesday 

If Time Unit is Day, the enter recurring time period module 15602 

displays nothing. 

If the actor sets the Recurring Period Type to Count Limited, the 
enter recurring time period module 15602 displays theNumber of Recurrences. This 
controls the number of recurring dates within the whole period. 

If the actor sets the Recurring Period Type to Date Limited, the enter 
recurring time period module 15602 displays the End Date field. This controls the 
number of dates within the whole period by ending the whole period at a certain date. 
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Modify Recurring Time Period 

The modify recurring time period use case 16002 is diagramed in FIG. 1 60. 
This use case is used by other use cases that must modify a recurring period of some 
kind in the Licensing Database 1204. The use case permits the actor to modify the 
5 existing repetition structure for the recurring period or to change the type of period 

completely between the two concrete types (date-limited and count-limited). The 
operation of this use case is further described below. 

Step 1. The actor passes in the object identifier for a time period to modify 
(:TimePeriod_ID). 

1 0 Step 2. The modify recurring time period module 1 6004 displays a data entry 

form containing the Time Unit (default Year), the Repetition (default 1), and the 
Recurring Period Type (default Count Limited), all displaying the current values for 
the time period the actor passes in (:TimePeriod_ID) queried from the Licensing 
database 1204. 

1 5 Step 3. The Actor changes the Time Unit, a Repetition, and/or the Recurring 

Period Type. 

Step 4. The modify recurring time period module 16004 returns the 
appropriate object back to the using use case. 

This use case has a number of extensions. 

20 ^ If the Recurring Period Type is Count Limited, the modify recurring 

time period module 16004 adds the Count_Lhiuted_Recurring_Period table to the 
following SQL queries as the <concrete subclass> and displays the Number of 
Recurrences. This controls the number of recurring dates within the whole period. If 
the actor changes the Recurring Period Type to Date Limited, the modify recurring 

25 time period module 16004 changes to display the End Date field and deletes the 

count-limited row when the transaction completes, replacing it with a new 
Date„Limited_Recurring_Period row. 
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° If the Recurring Period Type is Date Limited, the modify recurring 
time period module 16004 adds the Date_Limited„Recurring_Period table to the 
following SQL queries as the <concrete subclass> and displays the End Date field. 
This controls the number of recurring dates within the whole period by ending the 
period at a certain date. If the actor changes the Recurring Period Type to Count 
limited, the modify recurring time period module 16004 changes to display the 
Number of Recurrences field and deletes the date-limited row when the transaction 
completes, replacing it with a new Count_Limited_Recurring_Period row. 

** Depending on the Time Unit, the modify recurring time period 
module 16004 displays a set of options that the actor can use to control complex 
recurring structures. 

If Time Unit is Year, the modify recurring time period module 1 6004 
queries the Yearly options, displays them, and allows the actor to modify the options, 
choosing between two sets: 

Specific Month and Specific Day: June 15th. November 2 
° Ordinal Week of Month and Day of Week and Specific 
Month: first Tuesday in January 

° If Time Unit is Quarter, the modify recurring time period module 
16004 queries the Quarteriy options, displays them, and allows the actor to choose 
between three sets: 

Specific Day and Month: first day of second month of quarter 
° Specific Day of Week and Month: first Monday in second 
month of quarter 

° Specific Day: 45th day of quarter 
° If Time Unit is Month, the modify recurring time period module 
16004 queries the Monthly options, displays them, and allows the actor to choose 
between two sets: 

Specific Day: 15th, 21st 
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Ordinal Week of Month and Day of Week: first Tuesday of 

the month 

° IfTime Unit is Week, the modify recurring time period module 1 6004 
displays the Weekly options and allows the actor to enter the day of the week: 
Tuesday 

° IfTime Unit is Day, the modify recurring time period module 1 6004 
queries and displays nothing. 

Reports Use Cases 

Reports are a critical part of the Licensing module 1 102. It is through reports 
that the license administrator and auditor (or any other user) obtain a great amount of 
useful information from system. All available reports are listed in a reports pane 
10804 of a reports view 10802 (HG. 108). 

Preferably, a report engine is used to generate the reports. When the user 
selects a report, the licensing system 1 102 generates one or more commands that 
collectively encapsulates the user-selected report type and any user-provided 
parameters. The details of these commands will be apparent to persons skilled in the 
relevant art(s). These commands are in the language of the report engine. The report 
engine generates the report pursuant to the commands. In doing so, the report engine 
accesses data (as indicated in the commands) in the databases discussed herein. In an 
embodiment, a commercial reporting module is used as the report engine, such as the 
commercially available Crystal Reports product. 

Generate Report 

The generate report use case 10902 is diagramed in FIG. 109. The License 
Manager or Auditor (the "Actor") requests a particular report from a Hst the Generate 
report module 1788 displays. The Generate report module 1788 runs and displays or 
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prints the selected report. Preferably, to run a report on an individual object, the Print 
Object use case or related print use case is used. The operation of this use case is 
further described below. 

Step 1. The Actor begins the transaction to run a report. 

Step 2. The Generate report module 1788 constructs a list of available, 
reports, displaying the name and description for the report in the reports view 10802 
(HG. 108). 

Step 3. The Actor selects a report and requests that it be run, supplying 
appropriate parameters through a parameter form as requested and required, including 
the report destination (print or screen or file), ending the transaction. 

Step 4. The Generate report module 1788 runs the report and sends it to the 
indicated destination. 

The following are examples of reports: These are presented for illustrative 
purposes, and the invention is not limited to these examples. The invention is 
directed to include any reports of interest that can be generated from the information 
contained in the databases described herein. Implementation of these and other 
reports will be ^parent to persons skilled in the relevant art(s). It is noted that license 
related reports can be in a plurality of forms, such as those shown in the figures, and 
in forms including hyperbolic trees (described above). 

° Payment exception report: This report tracks the payment amount 
allocated to a license agreement and compares it to the expected revenue amount 
providing a balance due. Discrepancies between the expected revenue and the 
allocated revenue are flagged preferably in red within parenthesis. An example 
payment exception report is shown in FIGS. 1 lOA-1 IOC. 

° IP Asset - Agreement Financial Detail (Summary of InteUectual 
Property): This report lists the license agreements for each licensed IP asset package, 
providing the payment amount allocated to the asset package and the expected 
revenue. An example IP Asset - Agreement Financial Detail (Summary of 
Intellectual Property) report is shown in FIGS. 1 1 1 A-1 1 ID. 
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° Licensee Profile: This graph and detail report provides an overall view 
of a licensee's agreements. The graph presents total allocated payments and total 
expected revenue for each agreement. An example Licensee Profile report is shown 
inHGS. 112A-112F. 

Agreement Summary: The purpose of this report is to provide "front 
page" agreement and contact information and to Ust the compensation terms of the 
agreement. An example of this report is shown in FIG. 1 13. 

° Licensee Asset Package Sunmiary: The purpose of this report is to 
sunmiarize which asset packages and individual assets are licensed by each licensee. 
An example of this report is shown in FIGS. 1 14A and 1 14B. 

° Payment Allocation Report: This report lists the payments for each 
agreement and the breakout for each IP asset. An example of this report is shown in 
HGS. 115A-115C. 

° Royalty Statement Summary: This report lists the royalty statements 
for each agreement providing the line item details for each royalty statement. An 
example of this report is shown in FIG. 1 16. 

IP Asset - Historical Royalties: This report for each asset in a licensed 
package lists the agreements that license out the asset and provides a running total of 
royalties earned. An example of this report is shown in FIG. 1 17. 

The Summary of hitellectual Property Report relates an P asset to its 
overall licensing revenue. 

° The Intellectual Property Licensee Summary Report provides a 
summary of agreements for each licensee. 

° The Royalty Expense Allocation Report tracks royalty earnings posted 
in the General Ledger but not yet verified. 

The Licensee Historical Earned Royalty Graph shows Guaranteed 
Minimum, Actual Payment, Expensed payment, and Term Required totals for a 
specified Licensee by time period (date range or audit period selection). 
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The IP Historical Earned Royalty Graph shows G/L total and 

Expensed total for an IP Asset. 

The Overdue Payment Graph shows Statement Received dates. Term 
total by due date. Payment total by payment date with some sort of flag and value for 
overdue interest owed or paid. 

The Draft License is a report that is in the form of a license agreement 
document, that is generated by the system based on information in the databases. This 
draft document can be modified as necessary to produce the actual Hcense agreement 
document. 

Security Use Cases 

In an embodiment, Licensing system security includes the security features 
described above. In other embodiments, Licensing system security includes any 
combination of the above with one or more other features, such as the following 
administrative use cases, the ability to assign a security classification in the various 
document and payment entry and modification use cases, and the ability to change 
privileges on asset groups. 

Administer Entitles (Users) 

The administer users use case 1 1 802 is diagramed in FIG. 118. According to 
this use case, the system Administrator creates, modifies, and/or removes users fi-om 
the core database 1208. 

Step 1. The System Administrator starts the transaction. 

Step 2. The Administer entities module 1715 displays a list of users ordered 
by name, displaying the User Name, User Full Name, and Password (the password 
field appears but the actual password does not); there is also a Confirm Password for 
validating password entry. 
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Step 3. The System Administer takes one of the following actions: 

Step 3.1. The System Administrator creates a new User, 
entering the User Name, the Full_Name, and the Password (twice) (the Administer 
entities module 1715 generates the User ID). The Administer entities module 1715 
5 encrypts the password. 

Step 3.2. The System Administrator selects one of the current 
Users and modifies the Name, the Full Name, or the Password. 

Step 3.3. The System Administrator selects one of the current 
Users and removes it. 
1 0 Step 4. The System Administrator ends the transaction. 

Steps. The Administer entities module 17 15 commits the changes in the core 
database 1208. The Administer entities module 1715 confirms the commit to the 
System Administrator. 

This use case has a number of extensions: 
15 If the System Administrator presses Fl or the equivalent, the 

application extends the use case with the Display Help use case. 

° If removing a User, the Administer entities module 1715 deletes the 
information from the Licensing database 1204 and moves it to the Recycle Bin 
(implementation may differ regarding details on deferring the actual SQL deletes, and 
20 there is no notification of commit to the System Administrator). The Administer 

entities module 1715 confums the commit to the System Administrator. At any time 
until clearing the Recycle Bin, the administrator can restore the removed User and its 
related information. 

Administer Security Classes 

25 The administer security classes use case 1 1902 is diagramed in FIG. 119. 

According to this use case, the system Administrator sees a list of all security classes. 
The system Administrator can add a new class to the list, can modify the name and 
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access control list of a class, or can remove a class. This use case is further described 
below. 

Step 1. The System Administrator starts the transaction. 

Step 2. The Administer security classes module 1717 displays a list of 
Security Classes, displaying the Security Class ID and Name, and a list of the Entities, 
displaying the Entity JD and User Name. 

Step 3. The System Administer takes one of the following actions: 

Step 3.1. The System Administrator creates a new Security 
Class, entering the Name (the Administer security classes module 1717 generates the 
Security Class ID), and requests that the IP AM Security Subsystem create the object. 

Step 3.2. The System Administrator selects one of the current 
Classes and modifies the Name. 

Step 3.3. The System Administrator selects one of the current 
Security Classes and requests that the IP AM Security system 1602 remove it. 

Step 3.4. The System Administrator selects a Security Class. 
The Administer security classes module 1717 displays the permissions for that 
Security Class for each Entity. The System Administrator then modifies the 
permissions for any entity, including those with no permissions. The System 
Administrator requests the IP AM Security Subsystem 1 602 to set the permissions for 
the modified Security Class and Entities. 

Step 4. The System Administrator ends the transaction. 

Step 5. The Administer security classes module 1717 commits the changes 
in the Licensing Database 1204. The Administer security classes module 1717 
confirms the commit to the System Administrator. 

At any time, if the System Administrator presses Fl or the equivalent, the 
^plication extends the use case with the Display Help use case. 
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Grant Permissions 

The grant permissions use case 12002 is diagramed in FIG. 120. According 
to this use case, the System Administrator selects a secure object (an asset package 
or classifier), selects an entity (user or user group), and grants read, write, and/or 
5 delete permission to the entity for the object. The grant permissions module 1719 

makes the permissions permanent through the IPAM Security Subsystem 1602. This 
use case is further described below. 

Step 1. The System Administrator starts the transaction. 

Step 2. The Grant permissions module 1719 displays a list of the secure 
10 objects to which the System Administrator has access based on their current 

authentication user name. It gets this from the IPAM Security Subsystem 1602. The 
Grant permissions module 1719 displays the objects sorted into two groups, asset 
packages and classifiers, distinguishing them by type (an icon, separate panes, or 
whatever). The asset packages display the Package OID and the Name. The classifiers 
1 5 display the Security Class OID and the Name. 

Step 3. The System Administrator selects a secure object. 

Step 4. The Grant permissions module 1719 displays a control that lists 
available entities ordered by entity type and name, which it gets through the IPAM 
Security Subsystem 1602. 
20 Step 5. The System Administrator selects one or more entities. 

Step 6. The Grant permissions module 1719 displays the current permission 
settings on the secure objects (Read, Write, Delete), distinguishing settings that are 
the same for all selected secure objects and entities from those that are different (for 
example, a greyed check mark). 
25 Step 7. The System Administrator sets the permission flags (Read, Write, 

Delete) to new values as required, then ends the transaction. 
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Step 8. The Grant permissions module 1719 passes the changes to the DP AM 
Security Subsystem 1602, which updates the security tables in the Core Database 
1208. 

Administer Roles 

The administer roles use case 1 2402 is diagramed in FIG. 1 24. According to 
this use case, the System Administrator creates, modifies, and/or removes roles from 
the Licensing database 1204. The operation of this use case is further described 
below. 

Step 1 . The System Administrator starts the transaction. 

Step 2. The Administer roles module 1721 displays a list of Roles, displaying 
the Role K). Name, and Etescription. 

Step 3. The System Administer takes one of the following actions: 

Step 3.1. The System Administrator creates a new Role, 
entering the Name and Description (the Administer roles module 1 72 1 generates the 
Role E)) 

Step 3.2. The System Administrator selects one of the current 
Roles and modifies the Name or the Description. 

Step 3.3. The System Administrator selects one of the current 
Roles and removes it. 

Step 4. The System Administrator ends the transaction. 
Step 5. The Administer roles module 1721 commits the changes in the 
Licensing database 1204. The Administer roles module 1721 confirms the commit 
to the System Administrator. 

This use case has a number of extensions: 

° If the System Administrator presses Fl or the equivalent, the 
application extends the use case with the Display Help use case. 
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° If removing a Role, the Administer roles module 1721 deletes the 
information from the licensing database 1204 and moves it to the Recycle Bin 
(implementation may differ regarding details on deferring the actual SQL deletes, and 
there is no notification of commit to the System Administrator). The Administer roles 
module 1721 confirms the commit to the System Administrator. At any time until 
clearing the Recycle Bin, the administrator can restore the removed Role and its 
related information. 

Currency Use Cases 

The various monetary amounts in Licensing module 1102 may be in any 
currency. This can cause problems when payments, royalty statements, and 
compensation terms list the amounts in different currencies. The Convert Currency 
use case provides a currency conversion mechanism for the generate report module 
1788. This is visible to the user when the user takes an action that needs to operate on 
amounts in different currencies. 

Currency conversion depends on a database of conversion ratios. These ratios 
vary over time. Depending on the customer's needs, the customer could want to have 
a different ratio every day, every month, or every year. Or, they could just want a 
single conversion rate. The Maintain Currency Conversions use case coiresponds to 
a menu entry that lets the License Administrator enter open-ended time intervals and 
conversion ratios that hold during those intervals. 

Convert Currency 

The convert currency use case 12202 is diagramed in FIG. 122. This use case 
is used by several other use cases to convert monetary amounts. The User passes the 
monetary amount, the currency, and the date to the use case. The Convert currency 
module 1 790 converts the currency using the currency conversion intervals from the 
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Licensing database 1204 and returns the dollar amount. The operation ofthis use case 
is further described below. 

Step 1 . The using use case passes in the monetary amount, the currency object 
identifier, and the date of the transaction. 
5 Step 2. The Convert currency module 1 790 looks up the currency conversion 

rate in the licensing database 1204. The conversion rate depends on the date of the 
transaction, because currency rates fluctuate with time. 

Step 3. The Convert currency module 1790 returns the converted amount in 

dollars. 

10 This use case has a number of extensions: 

° If the currency doesn't exist, the Convert currency module 1790 
displays an error message: "Currency <oid> doesn't exist." 

If there are no currency intervals for the currency with a date less than 
or equal to the transaction date, the Convert currency module 1 790 displays an error 
1 5 message: "No conversions for currency as of <Transaction Date>". 

Maintain Currency Conversions 

The maintain currency conversions use case 1 2302 is diagramed in FIG. 1 23 . 
According to this use case, the License Administrator performs various currency 
maintenance functions: 
20 ° Adding a new currency 

^ Modifying an existing currency 
° Removing a currency 
° Adding a new currency conversion interval 
Removing an exisdng interval 
25 ° Modifying an existing interval 

The operation of this use case is further described below. 
Step 1. The License Administrator begins the transaction. 
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Step 2. The Maintain currency use case 12302 displays a list of currencies, 
displaying the Unit Name, Country, and Unit Symbol for the currency: 

Step 3. The License Administrator selects a currency or adds a new currency. 
The License Administrator optionally changes the Unit Name, Country, or Unit 
Symbol or removes the currency. 

Step 4. If the currency is new, the Maintain currency use case 12302 creates 
a new currency object identifier. The Maintain currency use case 12302 displays the 
time interval layout of the currency, displaying the Start Date, the Dollar Conversion 
Rate, and the Description, if any: 

Step 5. The License Administrator selects an interval, if there are any. 

Step 6. The License Administrator removes the selected interval or changes 
the Start Date, Dollar Conversion Rate, or Description fields. 

Step 7. The License Administrator repeats steps 3-6 or conmiits the 
Uransaction. 

Step 8. The Maintain currency use case 12302 inserts any new currencies, 
updates any changed currencies, and deletes any removed currencies (including any 
currency intervals). The Maintain currency use case 12302 inserts any new intervals, 
updates any changed intervals, and deletes any removed intervals. The Maintain 
currency use case 12302 confirms the commit to the License Administrator. 

This use case has an extension. Specifically, if the License Administrator 
wants to add a new interval to the existing set, the Maintain currency use case 12302 
displays the new interval at the bottom of the list of current intervals. The License 
Administrator enters the Start Date, the Description, and the Dollar Conversion Rate. 
When the License Administrator selects another interval, the Maintain currency use 
case 1 2302 sorts the list and puts the new interval in its proper place in the list ordered 
by date. 
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Top Level Operational Examples Of the Licensing System 

An example thread of operation through the licensing system 1 102 shall now 
be described with reference to a flowchart 12502 in FIG. 125. In should be 
understood that the present invention, including the licensing system 1 102, is very 
powerful, very flexible, very adaptable, and very user-responsive. According to the 
invention, users can employ and/or adapt the functions, modules, components, 
objects, etc., describe herein to pursue their own strategies, goals, needs, 
requirements, desires, etc. Users are not limited to the particular examples described 
herein, such as the example in FIG. 125. Accordingly, it should be understood that 
the example of FIG. 125 is provided for purposes of illustration, and is not limiting. 

In the following, the steps are said to be performed by a "user." Generally, 
this user can be any person desiring to use the licensing system 1 102, including any 
of the actors described herein. Also, different users can perform different steps. 

In step 12504, the user defines entities. These entities will later be assigned 
to roles, such as licensee and licensor. See, inter alia, the Administer Entity use case. 

In step 12506, the user creates IP (intellectual property) assets. This involves 
entering patent assets if the licensing system 1 102 is not integrated with the IP AM 
database 216. If the licensing system 1 102 is integrated with the IP AM database 216, 
then there is no need to enter patent assets as such patent assets are accessible from 
the IP AM database 2 1 6 (although in some embodiments, the user is allowed to enter 
patent assets even when the licensing system 1 102 is integrated with the ff AM 
database 216, since, for example, the IPAM database 216 may not include all U.S. 
and/or foreign patents, reissues, reexaminations, etc.). This step also includes entering 
trademark assets, entering trade secret assets, entering copyright assets, entering know 
how assets, etc. See, inter alia, the Enter Patent, Enter Trademark, Enter Copyright, 
Enter Trade Secret, and Enter Know How use cases. 

In step 12508, the user creates asset packages. Each asset package includes 
IP assets to license. There are three types of asset packages: standard, group, and 
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descriptive. When entering a standard asset package, the user manually selects assets 
for inclusion into the asset package (this can be done via drag and drop operations, for 
example). When entering a group asset package, the user selects an IP AM group. 
The assets in the IP AM group become the contents of the asset package. When 
entering a descriptive asset package, the user provides a description of the assets being 
licensed, such as "All patents and patent applications currently existing as of June 1 8, 
1997." See, inter alia, the Create IP Asset Package use case. 

In step 12510, optionally, the user provides a revenue allocation percentage 
for each asset in an asset package. An asset's revenue allocation percentage within 
an asset package indicates the degree to which that asset contributed to license 
revenue attributed to the asset package. For example, if an asset within an asset 
package has an allocation percentage of 65%, and a license revenue of $100 is 
attributed to the asset package, then that asset is considered to have been responsible 
for generating $65 of the $100 license revenue. See, inter alia, the Create IP Asset 
Package use case. 

In step 125 12, the user creates a license agreement. See, inter alia, the Enter 
License Agreement use case. In doing so, the user specifies the parties to the 
agreement, such as the licensee(s) and the licensor(s). These parties are entities who 
were defined in step 12506. See, inter alia, the Link to Party use case. 

The license agreement is an instrument that operates to license IP assets from 
the licensor(s) to the licensee(s). According to an embodiment of the invention, the 
IP assets that are being licensed via the license agreement are specified via asset 
packages. Specifically, in step 125 12, the user identifies one or more asset packages 
that contain the IP assets that are desired to be licensed via the license agreement. 
These identified asset packages are linked to the license agreement. See, inter alia, 
the Link to Asset Package use case. 

A license agreement includes a number of terms agreed upon by the parties, 
such as whether the hcense is limited to particular territories, whether the license is 
exclusive or not exclusive, whether the license includes grant back provisions, etc. 
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Importantly, a license also includes compensation terms, which specify the 
compensation that the licensee pays to the licensor for the benefit of receiving the 
license to the EP assets contained in the linked asset packages. Accordingly, also in 
step 12512, the user enters compensation terms for the license. See, inter alia, the 
Enter Compensation Term use case. 

In step 12514. optionally, the user determines the expected revenue of the 
license agreement. This is preferably done on a per compensation term basis. 
Specifically, for each compensation term, a schedule of expected future revenue 
payment(s) is calculated, based on the type and characteristics of the term. For 
example, if Tennl is a lump sum payment of $100 to be paid on January 1, 2000, 
then the expected revenue of Term 1 is calculated to be $100 to be received by the 
licensor on January 1 , 2000. If Term2 is an ongoing royalty based on per unit sales, 
where the royalty rate is $1 per 100 units and the estimated unit sales is 1000 per 
period (specified via the Enter Compensation Term use case), then the expected 
revenue of Term2 is calculated to be $ 10 per period. These expected future revenue 
payments are displayed in the expected revenue tab 9608 of the payment dialog 9602 
(FIG. 96). See, inter alia, the Enter Compensation Term and Create Expected 
Revenue use cases. 

In step 1 25 1 6, the user receives a royalty statement related to the license from 
the licensee. Licensees are typically required to send such royalty statements to the 
licensor, such as on a quarterly basis. The user enters the royalty statement into the 
system. This includes entering the period to which the royalty statement applies. This 
also includes entering the details of the royalty statement, where each detail 
corresponds to a product, the number of units of the product sold during the period, 
the revenue generated by the sales, and the royalty due. This information is obtained 
fi-om the royalty statement. See, inter alia, the Enter Royalty Statement use case. 

In step 12518, the user receives a license revenue payment related to the 
license. The user enters the payment into the system. This includes entering the 
amount of the payment. Optionally, this also includes allocating the payment to terms 
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of the license. See FIG. 98. For example, assume that a license has temis Terml and 
Term2. and that in step 1 25 1 4 it was calculated that on a per period basis the expected 
revenue of Terml is $100, and the expected revenue of Tenn2 is $200. Assume that 
the payment is for $275. In step 12518, the user may elect to allocate $100 of the 
$275 payment to Terml, and the remaining $175 of the $275 payment to Term2. In 
this example, the expected revenue of Term 1 is fiiUy satisfied by the payment, but the 
expected revenue of Term2 is short by $25. This is an example of how the invention 
can aid the user in uracking license payments. 

Optionally, step 12518 also includes allocating the payment to details of 
royalty statements received by the licensor from the licensee. See FIG. 97. For 
example, suppose that a royalty statement having details Detail 1 and Detail2 are 
associated with the license agreement. Detaill has an expected royalty of $125, and 
Detail2 has an expected royalty of $250. Assume that the payment is for $275. In 
step 125 18, the user can elect to allocate $ 125 of the $275 payment to Detail 1 , and the 
remaining $150 of the $275 payment to Detail2. In this example, the expected 
royalty of Detail 1 is fully satisfied by the payment, but the expected royalty of Detail2 
is short by $100. This is another example of how the invention can aid the user in 
tracking license payments. 

With regard to the operation of step 1 25 1 8, see, inter alia, the Enter Payment, 
Modify Payment, Link to Expected Revenue, and Link to Detail use cases. 

In step 12520, the user runs reports based on his needs, requirements, 
interests, etc. Examples of reports supported by the invention include, but are not 
limited to: compare payments to royalty statement details; compare payments to 
expected revenue; determine the revenues (payments) attributable to each asset in an 
asset package; and any other report discussed herein. It is noted that the invention is 
not limited to the reports discussed herein. Any report, particularly any financial 
related report, relating to the subject matter discussed herein and/or derivable from the 
data discussed herein is contemplated by the invention. Implementation of such 
reports will be apparent to persons skilled in the relevant art(s). 
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Conclusion 

While various embodiments of the present invention have been described 
above, it should be understood that they have been presented by way of example only, 
and not limitation. Thus, the breadth and scope of the present invention should not 
be limited by any of the above-described exemplary embodiments, but should be 
defined only in accordance with the following claims and their equivalents. 
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What Is CMmed Is: 

1. A computer based method of managing intellectual property (BP) related 
transactions, comprising the steps of: 

( 1 ) accessing a database comprising information representative of at least 
one IP asset; 

(2) accessing adatabase comprising information representative of at least 
one JP asset package each comprising one or more of said at least one IP asset; 

(3) accessing a database comprising information representative of at least 
one license agreement each associated with one or more of said at least one IP asset 
package; and 

(4) enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, (b) said at 
least one JP asset package, and (c) said at least one license agreement. 

2. The method of claim 1, further comprising the steps of: 

(5) accessing a database comprising information representative of at least . 
one royalty statement each associated with one or more of said at least one license 
agreement; 

(6) accessing a database comprising information representative of at least 
one payment each associated with one or more of said at least one license agreement; 
and 

(7) enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, (b) said at 
least one IP asset package, (c) said at least one license agreement, (d) said at least one 
royalty statement, and (e) said at least one payment. 

3. The method of claim 1 , further comprising the step of: 
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(8) accessing a database comprising information representative of entities 
and entity roles; 

wherein said at least one license agreement specifies one or more of said 
entities as parties to said at least one license agreement. 

4. The method of claim 1 , wherein said at least one BP asset comprises at least 
one of: (a) a patent asset, (b) a copyright asset, (c) a trade mark asset, (d) a trade secret 
asset, and (e) a know how asset. 

5. The method of claim 1 , wherein said at least one IP asset package comprises 
at least one of; (a) a standard IP asset package, (b) a group IP asset package, and (c) 
a descriptive IP asset package. 

6. The method of claim 5, wherein said standard IP asset package comprises any 
user selected combination of said at least one IP asset. 

7 . The method of claim 5 , wherein said group DP asset package i s associated with 
a group, said group IP asset package comprising any assets in said group. 

8. The method of claim 7, wherein said group includes one or more patents, and 
wherein said group IP asset package comprises said one or more patents. 

9. The method of claim 5, wherein said descriptive IP asset package is 
associated with a description, and wherein said descriptive IP asset package comprises 
assets satisfying said description. 

10. The method of claim 1 , wherein said at least one IP asset package comprises 
a revenue allocation percentage for each of said at least one IP asset in said at least 
one IP asset package. 
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1 1 . The method of claim 1 , wherein said at least one license agreement comprises 
one or more user specified compensation temis. 

12. The method of claim 1 1 . wherein said at least one license agreement fiirther 
comprises information pertaining to expected revenue of said at least one license 
agreement. 

13. The method of claim 12. wherein said expected revenue is automatically 
calculated for said one or more user specified compensation terms. 

14. The method of claim 2, wherein said at least one royalty statement comprises 
information pertaining to one or more royalty statement details, wherein each of said 
one or more royalty statement details corresponds to a product and comprises 
information indicative of a number of units of the product sold during a period of said 
at least one royalty statement, revenue generated by the sales, and royalty due. 

15. The method of claim 2, wherein said at least one payment is allocated to one 
or more terms of said at least one license agreement. 

16. The method of claim 2, wherein said at least one payment is allocated to one 
or more details of one or more royalty statements associated with said at least one 
license agreement. 

17. The method of claim 2, wherein step (4) comprises the steps of: 

(i) comparing any payment amounts allocated to said at least one license 
agreement to any expected revenue amounts of said at least one license agreement; 
and 

(ii) generating a payment exception report based on results of step (i). 
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18. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating an IP asset report listing any license agreements involving 
said at least one IP asset package, wherein the IP asset report includes information 
indicative of any payment amounts allocated to said at least one IP asset package, and 
any expected revenue of said at least one IP asset package. 

19. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a licensee profile report comprising information indicative 
of total allocated payments and total expected revenue for each of said at least one 
license agreement. 

20. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating an agreement summary report comprising information 
indicative of at least contact information and compensation terms of said at least one 
license agreement. 

21 . The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a licensee asset package summary report comprising 
information indicative of any asset packages and any IP assets licensed to each 
licensee. 

22. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a payment allocation report comprising information 
indicative of any payments associated with said at least one license agreement, and 
allocation of said any payments to terms of said at least one license agreement, 

23. The method of claim 2, wherein step (4) comprises the step of: 
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(i) generating a royalty statement summary report comprising 
information indicative of any royalty statements, and details of said any royalty 
statements, associated with said at least one license agreement. 

24. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a historical royalties report listing any license agreements 
that license an IP asset, and comprising information indicative of royalties earned for 
said IP asset per license agreement. 

25. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a summary of IP report comprising information indicative 
of overall licensing revenue of an ff asset. 

26. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating an IP license summary report that provides a summary of 
license agreements for each licensee. 

27. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a royalty expense allocation report that tracks royalty 
earnings posted in a general ledger but not yet verified. 

28. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating a licensee historical earned royalty report comprising 
information indicative of Guaranteed Minimum, Actual Payment, Expensed payment, 
and Term Required totals for said at least one Ucense agreement. 

29. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating an IP historical earned royalty group comprising 
information indicative of G/L total and Expensed total for an JP Asset. 
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30. The method of claim 2, wherein step (4) comprises the step of: 

(i) generating an Overdue Payment report comprising information 
indicative of Statement Received dates, Term total by due date, and Payment total by 
payment date. 

3 1 . The method of claim 1 , wherein said at least one license agreement comprises 
one or more tenms related to at least one of territorial restrictions and field-of-use 
restrictions. 

32. The method of claim 11, wherein said one or more user specified 
compensation terms comprises one or more of an ongoing royalty per unit term, 
royalty per sales term, minimum guarantee term, advance term, ongoing fee term, and 
lump sum fee term. 

33. The method of claim 11, wherein said one or more user specified 
compensation terms comprises at least one term that includes a recurring payment. 

34. A computer based method of managing intellectual property (IP) related 
transactions, comprising the steps of: 

( 1 ) accessing a database comprising information representative of at least 
one IP asset; 

(2) accessing a database comprising infomiation representative of at least 
one license agreement each associated with one or more of said at least one IP asset; 
and 

(3) enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, and (b) said 
at least one license agreement. 

35. The method of claim 34, fiirther comprising the steps of: 
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(4) accessing a database comprising information representative of at least 
one royalty statement each associated with one or more of said at least one license 
agreement; 

(5) accessing a database comprising information representative of at least 
one payment each associated with one or more of said at least one license agreement; 
and 

(6) enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, (b) said at 
least one license agreement; (c) said at least one royalty statement; and (d) at least one 
payment. 

36. A system for managing intellectual property (P) related transactions, 
comprising: 

means for accessing a database comprising information representative of at 
least one IP asset; 

means for accessing a database comprising information representative of at 
least one license agreement each associated with one or more of said at least one IP 
asset; and 

means for enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, and (b) said 
at least one license agreement. 

37. The system of claim 36, further comprising: 

means for accessing a database comprising information representative of at 
least one royalty statement each associated with one or more of said at least one 
license agreement; 

means for accessing a database comprising information representative of at 
least one payment each associated with one or more of said at least one license 
agreement; and 
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means for enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one JP asset, (b) said at 
least one license agreement; (c) said at least one royalty statement; and (d) at least one 
payment. 

38. A computer program product comprising control logic stored in a computer 
useable medium, said control logic comprising: 

means for enabling a computer to access a database comprising information 
representative of at least one IP asset; 

means for enabling a computer to access a database comprising information 
representative of at least one license agreement each associated with one or more of 
said at least one IP asset; and 

means for enabling a computer to enable processing of, in a manner specified 
by a user command, information representative of at least one of: (a) said at least one 
IP asset, and (b) said at least one license agreement. 

39. The computer program product of claim 38, wherein said control logic further 
comprises: 

means for enabling a computer to access a database comprising information 
representative of at least one royalty statement each associated with one or more of 
said at least one license agreement; 

means for enabling a computer to access a database comprising information 
representative of at least one payment each associated with one or more of said at 
least one license agreement; and 

means for enabling a computer to enable processing of, in a manner specified 
by a user command, information representative of at least one of: (a) said at least one 
IP asset, (b) said at least one license agreement; (c) said at least one royalty statement; 
and (d) at least one payment. 
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40. A method of managing intellectual property (IP) related transactions, 
comprising the steps of: 

( 1 ) enabling a user to enter information representative of at least one IP 

asset; 

5 (2) enabhng a user to enter information representative of at least one 

license agreement each associated mih one or more of said at least one IP asset; and 

(3) enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, and (b) said 
at least one license agreement. 

10 41. The method of claim 40, further comprising the steps of: 

(4) enabling a user to enter information representative of at least one 
royalty statement each associated with one or more of said at least one license 
agreement; 

(5) enabling a user to enter information representative of at least one 
1 5 payment each associated with one or more of said at least one license agreement; and 

(6) enabhng processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, (b) said at 
least one license agreement, (c) said at least one royalty statement, and (d) said at least 
one payment. 

20 42. A system for managing intellectual prop>erty (IP) related transactions, 

comprising: 

means for enabhng a user to enter information representative of at least one 
IP asset; 

means for enabhng a user to enter information representative of at least one 
25 hcense agreement each associated with one or more of said at least one IP asset; and 
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means for enabling processing of, in a manner specified by a user command, 
information representative of at least one of: (a) said at least one IP asset, and (b) said 
at least one license agreement. 

43. The system of claim 42, further comprising: 

5 means for enabling a user to enter information representative of at least one 

royalty statement each associated with one or more of said at least one license 
agreement; 

means for enabling a user to enter information representative of at least one 
payment each associated with one or more of said at least one license agreement; and 
1 0 means for enabling processing of, in a manner specified by a user command, 

information representative of at least one of: (a) said at least one IP asset, (b) said at 
least one license agreement, (c) said at least one royalty statement, and (d) said at least 
one payment. 

44. A computer program product comprising control logic stored in a computer 
1 5 useable medium, said control logic comprising: 

means for enabling a computer to enable a user to enter information 
representative of at least one IP asset; 

means for enabling a user to enter information representative of at least one 
license agreement each associated with one or more of said at least one IP asset; and 
20 means for enabling processing of, in a manner specified by a user command, 

information representative of at least one of: (a) said at least one IP asset, and (b) said 
at least one license agreement. 

45. The computer program product of claim 44, wherein said control logic further 
comprises: 
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means for enabling a computer to enable a user to enter information 
representative of at least one royalty statement each associated with one or more of 
said at least one license agreement; 

means for enabling a computer to enable a user to enter information 
5 representative of at least one payment each associated with one or more of said at 

least one license agreement; and 

means for enabling a computer to enable processing of, in a manner specified 
by a user command, information representative of at least one of: (a) said at least one 
IP asset, (b) said at least one license agreement, (c) said at least one royalty statement, 
10 and (d) said at least one payment. 
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can be used by 



GROUP TABLE / 
group_ld 



IP 



group_fluid (AKO) 
name 

creation_date 
modification^d ate 
version_number 
description 
owner_user_ki (FK) 



has 



GROUP DOCUMENT XREF y 



document_(d (FK) <AK1) 
groupjd (FK) (AK1) 



modification_date 



@- 



belongs in 



GROUP GROUP XREF 



parent (FK) 
group_id (FK) 



sort order 



'can-be used by 
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CORPORATE ENTITY 



corp_entityJd 



corpJeveLkJ (FK) 
name 

parent_corp_entity_id (FK) 
sort_order 



Ry91 




PRIMAR Y CORP 



is defined as self 



corp_entity_id (R^ 



owns 



CORP PATENT XREF 



corp_entityJd (FK) 
documentjd (FK) 



ownership_id (FK) 
relevance_id (FK) 



PATENT OWNERSHIP / : 



ownershipjd 



description 



CORPORATE_LEVEL / 



corpjeveljd 



description 



defines the level of 



I 



employs 



R/96 



RELEVANCE 



relevance id 



description 



VALIDATED INVENTOR 

personjd (FK) 
documentjd (FK) 



corp_entityjd (FK) 




— o 
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GROUP USER XREF A ' 



group^id (FK) 
user_ld (FK) 



permission 



1 



has rights to 



USERTABLE 



USR GRP USR XREF 



t>elongs In 



userjgroup_id (FK) 
user__id (FK) 



id 



user_name (AKO) 

user_full_name 

password 



has 



GRP USR GRP XREF 



groupjd (FK) 
userjroup_ld (FK) 


1 


user_jgroup_id 


• ha&fl§Ws4o 


group_name (AKO) 


permission 
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PERSON 



plays the rolo of 



person_id 



first_name 
mldclle_name 
las^name 
suffix 



EMPLOYEE 



EMPLOYEE„TYPE 



person.kJ (FK) 
corp,entity_td (FK) 



part_time, 



job_function_ld (FK) 
eniployee_type_id (FK) 
employee_stalus_ld (FK) | 
start.date 

employse fd 

T 



employee_type_id 



description 



fuli_time, what? 




— 1 
I 

I 
I 

I 



EMPLOYEE JOB FUNC/ 



job_function_id 



description 



_active^nactiye_ 



EMPLOYEE STATUS 
employee_slatus_ld j 



description 
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Agreement Summary 



06/1 on 998 

Agreement (D Name 



Type 



LA145433556 



R4SMr6toUSPTO 5597619 



License 



Exduslvtty 
Assignabt _ 
TransterabI _ 
RevocabU _ 
ConftdentU [x 

Agreement Parties 



Effective Date Expiration Date 
04/15/1996 04/15/2010 

Description 



Name 

M olPfitlar flwD j ra t ems ,4PC^ 
HulIio Mnltmlaj'OyJleiiij' 

Compensation Terms 



Role Name 

Licensee 
0^ exL 0 Fax 

Licensor 
0-0-0 exL 0 Fax 



Description 



Description 



Late Fee 



Amount 
$20,000.00 
$0.00 



Term Type 
F 
R 



Copyright e 1 99S by SmartPatenis. Inc. SmartPatenls, Inc. ConfHtenliaL Do notdupOcate. 
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Licensee Asset Package Summ/ 




OG/10/1998 








Package Name Description 
US 5597619 




Package Typo 
Standard 


ASEOt 

USPTO 5597619 


Asset Tjrpe 
USPTO Document 




Ucanso Agroomonts 

Agreement ID Name 

LA14543356S Amgcn USPTO 5597619 


Effective Date EKpiration Date 
<W1S/1996 04/15tt010 


Agreement Type 
License 








DioSpuUfiti;Tecliiiolea*'^^'6ofpr 


Package Wanrw^*'*'SK^ ^ Description 
US 5597619 ^ 




Package Type 
Standard 


Asset 

USPTO 6597619 


Asset Type 
USPTO Document 




Uconso Agreements 
Agreement tO Name 

tA146433564 DiuOpdUTtui USPTO 5597619 


Effective Date Expiration Date 
04/15/1996 04/15/2010 


Agreement Typo 
Ucense 




Package Nanw Description 
Chemotherapy AppDcation Know How 




Pactcage Type 
Standard 


Asset 


Asset Type 
Technical Data 




Ucense Agreements 
Agraemont fD Name 


Effective Date Expiration Dale 
04/15/1996 04/15/2010 


Agreement Type 
License 








4Ufe^«edicJl Scitfiwes Corp* t.^K^|c^ \> 


Package Name Description 
Influenza Sanitary Mask Know How 




Package Type 

Standard 


Asset 

USPTO 5597619 


Asset Type 
USPTO Document 
Technical Data 




License Agreements 

Agreement ID Name 

LM45433562 Ufu Mud Tlu Mash Know How 


Effective Date Expiration Date 
04/15/1996 04/15/2010 


Agreement Type 
License 






^ 


Copyrights 199B by SmertPa tents. Inc. SmarPatonts, Inc. Confidsnfid. Do not dupicats. 
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Licensee Asset Package Summ. 




06/1CV1998 
















Wolticular Diui>ybtet«s;lnu E" 








Package Name Description 

Afl Patents 






Package Type 
Stand anJ 


Asset 

USPTO 5597619 
USPTO 32028 
EPOB560556 


Asset Type 
USPTO Document 
USPTO Document 
EPO Document 




license Agreements . . ^ 
Agreement ID Name L*POr-| t 
IA145433560 Moleoulat-Ok> RocliR Motecutar Logo 


Effective Date 
04/15/1996 


Expiration Date 
04/15^2010 


Agreement Type 

License 


Package Name Description 
Anti-£bolus Vaccine arxj Diagnost Test 






Package Type 
Standard 


Asset Asset Type 

Copyright 


License Agreements p 
Agreement ID Name t^J^S^*^ ^ 
LA1454335S9 McOcnilflr Rin Ebolus Program 


Effective Date 
04/15/1996 


Expiration Date 
04/15/2010 


Agreement Type 
License 


Package Name Description 
EPB 560556 






Package Type 

Standard 


Asset 

EPO B 560556 


Asset Type 
EPO Document 




License Agreements f 
Agreement 10 Name t**^?*^ 
LA145433557 MoluiAiUii Diu EP B 560556 


Effective Dale 
04/15/1996 


Expiration Date 
04/15/2010 


Agreement Type 
license 


Package Name DescripUon 
Influenza Sanitary Mask Know How 






Package Type 
Standard 


Asset 

USPTO 5597619 


Asset Type 
USPTO Document 
Technical Data 




License Agreements , * ^ 
Agreement ID Name C^'-^*^i CT 
LA14543355B WolaeutacBie FJu Mask Know How 


Effective Date 
04/15/1996 


Expiration Date 
04/15«010 


Agreenwnt Type 
Uoense 


Package Name Description 
Roche Molecular Logo 






Package Type 
Standard 


Asset 

USPTO TR 12345 


Asset Type 
Trademark 






Ucertse Agreements r 
Agreement ID Name V*>'^(^ ^ 
LA145433560 Me(ecylereitS~RDet» Molecular Logo 


Effective Date 
04/15/1996 


Expiration Date 
04/15/2010 


Agreement Type 
license 


Copyri^te 1996 by SmartPatents. Inc. SmvtPatents. Inc. Confidenlid. Do not duplcate. 
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Agraamant Type 


License 






It Allocation An. 

$15,000.00 






It Atlocatton Amount 
$1,000.00 






Bt Allocation Amount 
$2,000.00 


$18,000.00 


• 

M 
o 

g 

1 

1 

o 

1 

1 


04/15/1998 04/15/2010 


>nAmt 
100.00 




Allocation Percant Assc 
100% 


jnAmt 
300.00 




Allocation Percent Assi 
100% 


s§ 




Allocation Percent Assi 
100% 


• 


o 
a 




IS 












1« 








Payment Allocation R< 




Payment Amount Ltcense Alio 
$15,000.00 i 


Description 




Payment Amount License Atlo 
$1,000.00 


Description 




Payment Amount License Alio 
$2,000.00 


1 

1 
& 




t 

8 

"a 
1 

a 

IB 
c 

1 


T- 

i 
r 
3_ 

^ a 
E 
m 
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MoteeoterWEPB 560556 


Invoice Number Receipt Date 
06/10/1998 


Package Name 
EPB 560558 


Asset 

EPO 8 560555 


Invoica Number Receipt Date 
02/01/1998 


Package Name 

EP B 660556 


Asset 

EPOB 560556 


Invoice Number Receipt Date 

05/01/1998 


Package Name 
EPB 560566 


Asset 

EPO B 560556 


s 

c 
S 
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& 
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m 
« 

Ol. 

te 

E 


10/1998 
aemant ID 


145433557 


'ayment ID 
2 






>ayment ID 
11 






'aymant ID 

12 






Agreement Toti 
Copyrl0ht©1998 
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^ Royalty Statement Summary 




0&1IV1998 






Agreement ID Name / U>M<V^ ^ 


Effective Date Expiration Date 


Agreement Type 


IA145433556 Moteuilar Oto USPTO 5597619 


04/1S/19S6 04/15/2010 


Uoense 


Reporting P«riod Invoice Number Due Date 
2 01/01/i99o 


Receipt Date Investigation Window 
02/01/1993 




Line NumtMf Name 

1 Sanitary Mask 

2 MaskFQer 


Units Sold Revenue 
10 $8,000.00 
15 $U000.00 


Rf^alty Due 
$400.00 
$600.00 


AAA AA 

9ZD,0UU.Uu 


$1,000.00 


Reporting Period Invoice Number Due Date 


Receipt Date Investigation Window 
05/01/1998 




Line Number Name 

1 SanftafY Mask 

2 MaskRer 


Units Sold Revenue 
10 $16,000.00 
15 $24,000.00 


Royalty Due 
$800.00 
$1,200.00 


$40*000.00 


$2*000.00 


Agreement Total 

Agreement ID Name / ^ ^ 


' $60,000.00 


$3*000.00 


Effective Date Expiration Date 


Agreement Type 


LA145433597 MOiCLUitU uiu cr a 


04/15/1996 04/15«010 


License 


Reporting Period Invoice Number OueDaU.^ 


Receipt Date investigation Window 
01/03/1998 




Une Number Name 

1 Sanitary Mask 

2 MaskFBer 


Units Sold Revenue 
10 $10,000.00 
15 $10,000.00 


Royalty Due 
$500.00 
$500.00 


$20,000.00 


$1,000.00 


Reporting Period Invoice Number ^^f^^^^ 


Receipt Date Investigation Window 
04/05/1998 




Une Number Name 

1 Saratary Mask 

2 Mask Filer 


Units Sold Revenue 
10 $16,000.00 
15 $24,000.00 


Royalty Due 
$800.00 

$i;!oo.oo 


$40,000.00 


$2,000.00 


Agreement Total 


' " $60*000.00 


$3*000.00 


Ccpyrti^l© 1998 by SmatPatents, Inc. SmartPatenla, Ire ConSdenfid. Do not Ajpicate. 


1 
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,190^ 

Administar Security Oassas \} M C^i^tZlS^V 





IPAM Security 
Sut>sy5tdm 
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Grant Permissions M%1 Cp^^t 




A 

^^b^t'V Administrator 



A 

IPAM Security Subsystem 



/AO 
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License Adminisliatar 



Remcva Entity 



Cor* D<^^'l'*f 
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Ucensa Admirustrator 



Maintafn C uroncy 



Maintain Cunonqr 



licensing Database 



}11 
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y pJne entities '"^P^ 



I 



Create IP assets (enter patent zs&^ if not integrated with the IPAM database, enter trademark I _ ^ 
asse ts, enter trade secret assets, enter copyrigh t assets, enter know how assets, etc.) \ jQH)(f) 



. 13^8 

Create asset packages where each asset package includes IP assets to license (standard, group, L?/^*^^ 
descriptive). See the Create IP Asset Package use case. _J 



Optionally, for eai± asset in an asset package, provide an allocation percentage. An asset's 
allocation percentage indicates the degree to which that asset contributed to license ^^^^ 
attributed to the asset package. For example, if an asset has an allocation percentage of 65%, 
that asset is considered to have been responsible for generating $65 for eveiy $100 of license fees 
attributed to the asset package. See the Create IP Asset Package use case. 



Create a license agreement. See the Enter License Agreement use case. Specify the parties to the 
agreement fue., licensee(s) and licensor(s). See the Link to Party use case. Specify the IP that is 
being licensed by selecting one or more asset packages. See the Link to Asset Package use case. 
In one embodiment,^! assets in the selected asset packages are being licensed via the license 
agreement In another embodiment, only some of the assets in the selected asset packages are 
being licensed via the license agreement. Specify terms of the license agreement, include 
compensation terms and other terms. See the Enter Compensation Term use case. 



I' Determine expected revenue of the license agreement. This is done on a per compensation term 
basis. For each compensation term, a schedule of expected future revenue payment(s) is 
calculated, based on the type and characteristics of the term. For example, if Term 1 is a lump sum 
payment of $100 to be paid on January 1, 2000, then the expected revenue of Term 1 is calculated 
to be $100 to be received by the licensor on January. 1, 2000. If Term2 is an ongoing royalty 
based on per unit sales, where the royalty rate is $1 per lOQ units and the estimated unit sales is 
1000 per period, then the expected revenue of Term2 is calculated to be $10 per period. These 
expected future revenue payments are displayed in the expected revenue tab 27208 of the 
payment dialog 27202 (FIG. 272). See tiie Enter Compensation Term and Create Expected 

Revenue use cases. 



FIG. mk 
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1 



Receive a royalty statement related to the Ucense. Enter the royalty statement into the ^stem. 
This includes entering the period to which the royalty statement applies. This also includes 
entering the details of the royalty statement, where each detail corresponds to a product, the 
number of units of the produrt sold during the period, the revenue generated by the sales, and the 
royalty due. See the Enter Royalty Statement use case. 



I 



Recdve a payment related to the Bcense. Enter the payment into the system. This mchides enter 

the amount of the payment OptionaUy, this includes allocating the payment to terms of the 
license See FIG 274 OptionaDy, this also mcludes aflocating the payment to detaik of royalty 
statements received by the Ucensor from the licensee. See HG. 273. See the Enter Payment. 

Modify Payment. Link to Expected Revemie. atd Link to Detail use cases. 



X 



"H^ reports based on needs and interests. Examples: compare payments to royalty statement 
details; compare payments to expected revenue; determine the revenues (payments) attnbutable to 
each asset in an asset package; etc. ^ 



■3^ 



FIG. 30^ 
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Logical View 



ADO Package 



#pADOConn : _ConnectionPtr 
#bOpened : boot 
#lnUse : bool 



SessIonADO 



+OpenO 
-fExecuteO 
+QueryO 
^-CloseO 
+Use() 
^ReteaseO 
BeginTransO 
+ComnrutTrans() 
+RoIlbackTrans() 
+GetExceptionError() : string 
*lslnUseO : bool 
•*-lsOpen() : bool 





session 



SesslonCache 



#DSN ; string 
^Password : string 
tfUserName : string 



#CreateSessions() : SessionADO ' 
+GetSession() : SessionADO & 
+GetSesslonPtr() : SessionADO 
4lnstance() 



#pRS : _RecordsetPtf 



RecordSetADO 



K3etField(position : int) : FieldADO 
+GetField(name : string) : ReldADO 
IsBOFO : bod 
+lsEOF0 : booi 
+Requery() 
<*-SetADORecordSet() 
+MovePresrtousO 
+MoveLast() 
^+MoveNextO 



+MoveFirstO 



Query Result 



+lsBOF() : bool 
+lsEOF() : bool 
+MoveFlrstC) 
+MoveLast{) 
'*-MoveNext() 
MovePrevious{) 
+Execute() 
+Query() 
+RequeTy() 



Oatabase::Transaction 



transaction 



#pCmd : ^CommandPtr 



ffpFteld : FieldPtr 



FieldADO 



•t-GetBoolO : BoolValue 
+GetBoolNullable() : NulIableBooIValue • 
K3etDate(} : OateVatue 
•M3etDateNu!lable() : NullableDateValue 
+GetDouble() : DoubleVatue 
■*-GetDoubleNullable() : NultableDoubleValue 
+GetF!oat() : FloatValue 
+GetFloatNullabteC) : NullaWeFloatVaiue 
HSetLongO : LongValue 
^•GetLongNuUableO : Nullable LongValue 
+GetMoneyO : MoneyValue 
K^tMoneyNuUableO : NullsbteMoneyValue 
+GetPercent() : PercenfValue 
+GetPercentNuliable() : NullablePercentValue 
+GetShort(j : ShortValue 
•»-GetShortNullableO : NuflableShortValue 
+GetStringNullable() : NullableStringValue 
+GetTimestamp() : TimestampValue 
+GetTtmestampNuIlable() : NullableTimestampValue 
+lsNull() : bool 



CommandADO 



•AppendParameterO 
■ExecuteO 

+GetParameterValue() 

i-OueryO 

+Refresh() 

■*-SetParametefValue() 



Value 



'/M 
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Logical View 



IP Asset Package 



ctype» 

IPDocumentienum tPType 



€ Persistent* 
Core::Document 



Document Type'r 



•Persistent* 
IP Document 



^Document Number : ShortValue (alternate oid = 1} 
lH}escnption : NullableStringValue 
#t.ong Display Name : StringValue 
H^ing Date : NullableOateValue 
mie : NullableStringValue 
Mssue Date : NullableDateValue 
tfPubfication Date : NullableDateValue 
Ms In Repository : BoolValue 
#Calc Exp Date : NullableDateValue 
#ls Phantom : BoolValue 
iH^trst Assignee : NullableDateValue 
#Number of Assignees : ShortValue 
#Rr5t Inventor : NullableStringValue 
#Nunriber of Inventors : ShortValue 



+GelNumber() : ShortValue 
•KaetPublishlngOrganizationO : Pub Organization 
+GetlPKindO : IP Doc Kind 
+<3etType() : enum IPType 
'^GetDescriptionO : NullableStringValue 
-^GetLongDrsplayNameO : StringValue 
4GetFaingDate() : NullableDate 
H^etTitleO : StringValue 
4^ttssueDate(} : NullableDateValue 
^GetPubltcationDateO : NullableDateValue 
40etExpirationDate() : NullableDateValue 
H^etFirstAssigneeO ; StringValue 
♦GetNumberOIAssigneesO ; ShortValue 
fGetRrstlnventor() : NullableStringValue 
*GetNumberOflnventors() : LongValue 
HsInRepositoryO : BoolValue 
t-lsPhantom() : BoolValue 
HsReadOntyO : BoolValue 
t-SetDescription() 
»-SetLongDisplayName(} 
►SetTdingDateO 
►SetTitleO 
t^SetlssueDateO 
•SetPublicationDateO 
•SetExpirationDateO 
•SetFirstAssigneeO 
•SetNumberOfAssigneesO 
■SetFirsllnventor() 
•SetNumberOflnventorsf) 



-^Database 
Object 



«Persistenl» 
Intellectual Asset Kind 



^Description : NullableStringValue 



+GetDescripttonO : NullableStringValue 



#Name : StringValue 
#Description : NullableStringValue 



a Persistent* 
Know How 



lAKind 



-KTetNameO : StringValue 
+GetDescription() : StringValue 
+GetKind(} : Intellectual Asset Kind 
+lsTradeSecret() : BoofValue 
+SetName() 
•«-SetDescription() 



J 



Database 
Object 



a Persistent* 
Trade Secret 



+lsTradeSecret() 



Database 
Object 



•Persistent* 
Pub Organization 



^Description : StringValue 



+GelDescriptlon{) 
+GetKinds() : IPDocKindQueryResult 



IP Doc Kind I ) (alternate oid 1} 



PubOrganization 



Kinds 1.; 



•Persistent* 
IP Doc Kind 



*#Description : NullableStringValue 



+GelDescription{) : NullableString 
+GetPubliishingOrganization() : Pub Organization 
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^5 8/^93 



Logical View 



3e 



^Abbreviation : StringValue 
#Fun Name : StringValue 
ffOescfiptfon : NullableStringValue 



<[Pefststent» 
Terrttory 



-KSetAbbreviatbnO : StringValue 
+GetFullName() : StringValue 
•t-GetDescriptionO 

SetAbbreviationO 
+SetFuIIName() 
+SetDescnption() 

SetAsDefauttQ 



'^Database 
Object 



1..* 



#Cross Ucense : BoolVatue = false 
#Umitations : NullableStringValue 



Territorial Restrictions 



aPersistent» 
Field of Use 



^Display Name : StringValue 
^Description : StringValue 



GetDtsplayNameO : StringValue 
GetDescripUonO : StringValue 

+SetDisplayName{) 

+SetDescription() 

+SetAsDefault() ______ 



^Oatat>ase 
Object 



aPersistent» 
Licensed Package 



'KSetLimitationsO : StringValue 

GetAgreementO : UoenseAgreement 
-K3etPackage() : AssetPackage 
+GetTerritories() : TerritoryQueryResult 
+GetFieldsOfUseO : FiekJQueryResutt 

IsCrossUcenseO : BooIValue 
-*-SetLtmitatjons() 

AddTerritoryO 

•RemoveTerritoryO 
+AddFieldOfUse() 

+RemoveFieldOfUse() 

A 



Field of Use Restrictions 



<Persistent» 
Security::Secure Object 



«Persistent» 
TimePcriod.Fixed Interval 



«Perslstent» 
Core:: Document 



Capture Period 



Packages 



#Nan>e : StringValue 
^Description : NullableStringValue 



Documents 



aPerslstent» 
Packaged Document 



^Allocation Percent : PercentValue 
K5etAltocationPercent{) : PercentValue 
•i-SetAnocationPercent() 
»GetDocument() 



tf Persistent* 
Asset Package 



+GetName() : StringValue 
+GetOescription() : StringValue 
+GetCapture PeriodO 

JetDocumentsO : DocumentOueryResull 
+GetLicenses() : UcenseQueryResuIt 
^SetNan>e() 
^SetDescription() 
+AddDocument() 
■RemoveDocumentO 
+AddUcense() 
•RemoveLicenseO 
+ SetCapturePeriodQ 



-^Oiatabase 
Object 



Assets 



Package Type 



aPersistentp 



Core::Group 



Group Database 



Licenses 



«Persistenttt 
LicenseAgreement::Llcense Agreement 



Object 



tfPersistents 
Group Asset Package 



+GetGroupName() : StringValue 



0 Persistent* 
Standard Asset Package 



1 



Databas e 
Object 



1 



Database 
Object 



« Persistent* 
Descriptive Asset Package 



O— jSHndusion Criteria : StringValue 



DescriptiveAssetPackageO 
+GeUnclusionCriteria() : StringValue 
+SetlnciusionCriteria(j 
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Logical View 

Asset Palfkage Query Result Package 



Database: :QueryResult 



AssetPackageQuery Result 



+Query() : string 
NextQ : AssetPackage ' 



Standard AssetPackageQueryResult 



DescriptWeAssetPackageQueryResult 



+Quefy() : string 

•t-NextO : DescriptweAssetPackage * 



♦QueryO : string 

-t-Nextp : StandardAssetPackage ' 




PA 



GroupAssetPackageQueryResult 



+Query{) : string 

+Next() .: GroupAssetPackage * 



wo 00/11575 



1 &D/193> 



PCT/US99/19050 



Logical View 



Ass^ Package Traosactobtras 



DatBbese::Transaction O-i 



Find IP Asset Package 



+GetStandardPackages() : StandardAssetPaclcageQueryResult 
+GetDescriptivePackages() : DescriptiveAssetPackageQueryResI 
+GetGroupPackages() : GroupAssetPackageQueryResult 
+FfndPaclcages(command : CommandADO) : AssetPackageQue^Resutt 
•^ComrrwtQ ^ 



Find Territortes 



GetTerritoriesO : Territory Query Result 
+ComrTut() _^ 



Pind Fields of Use 



+GetFields(} : FieldQueryResult 
+Cornmitt) 



Create IP Asset Package 



ffpPackage : AssetPackage 



CrealePackageO 
#Dolt() 



Modify (P Asset Package 



#pPackage : AssetPackage * 



ModifyiPAssetPacksgeO 
ffPoltp 



Remove IP Asset Package 



#pPackage : AssetPackage 



+RemovePackage() 
#Oolt() 




Create Standard Package 



-t-CreatePackagep : AssetPackage * 



Create Group Package 



^CreatePackageQ : AssetPackage * 



Create Descriptive Package 



+CreatePackageQ : AssetPackage ' 
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.ogical View 



Asset Query Result Packtrge 



Database::QueryResult <] — 




wo 00/11575 



PCT/US99/19050 



Logical View 



Database ::Transactlon 



Asset Transactions 



Find IP Asset 



GetPTOPatentsO : PTOPatentQueryResuIt 
+GetEPOPatents() : EPOPatentsQueiyResuIt 
+GetPCTPatentsO : PCTPatentsQueryResult 
-KTeUPOPatentsO : JPOPatentsQueryResuIt 
♦GetTrademarksO : TrademarKQueryResuIt 
+GetCopyrightsO : CopyrightQueryResuIt 
+GetKnowHovv() : KnowHoivQueryResult 
•KSefTradeSecretsQ : TradeSecretResultSet 
+GetAssetsO : AssetQueryResuit 
•*-RndAssets(command : Command AOO) : AssetQueryResuit 
+Commit() 



Create Patent 



+CreateO 
DoltQ 



Create Copyright 



+Create() 
DoltQ 



Create Trade Secret 



■CreateO 
-DolU) 



Remove IP Asset 



+Remove() 
DoltQ 



Modify IP Asset 



+Modify() 
DoltQ 




; 7 0 
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Logical View 



Coripensation Package 



aPersistent» 
LicensBAgreement::Llcense Agreement 



€persistent» 
Payfnent::Payment 



* Payments 



1.1 



Database 
Q Object 



Temis 1./ {ordered} 



« Persistent* 
Payment:License Payment Allocation 



«Persistent» 
Compensation Term 



cDescription : NullableStringValue 
tt_ate Payment Interest Rate : NunableShortValue 

tAnrount : MoneyValue , 

•GetDescriptionO : NullableStringValue 
•GetAmountO : MoneyValue 
<3etCurrency() : Currency::CurTency 
KSetLatePaymentRateO : NullableShortValue 
K3etCompoundingPerlod() : Recurring Period 
•SetDescriptionO 
■SetAmount() 
•SetCurrencyO 
•SetLatePaymentRateO 
•SetCompoundingPeriodO 
'CreateForecastQ 




Currency 



«Per5lstent» 
Currency::Currency 



Expected Revenues 



• {ordered) 



1.1 



Expected Revenues 
Database _ 



Object 



« Persistent* 
Expected Ucense Revenue 



#Amount : MoneyValue 
#Oue Date : DateValue 
^Description : NuUableStringValut 



+GetAmount() : MoneyValue 
+GetDueDate() : DateVatue 
+GetDescriptton() : StringValue 
Expected UcenseRevenueQ 



Temr 



Type 



Compounding Period 



•Persistent* 
TimePeriodr.Recurring Period 



Compensation Term 



'/33 
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Logical View 



Comaeosattooini Term Pacj^g© 



aPersistenU 
Compensation: :Conipensatlon Term 



Term Type 



Database 
Object *■ 



Database 
Object ^ 



Database, 
Object 



Database 
Object 



#Due Date : DateValue 
#Refundable : BoolVatue = 



aPerslstent» 
Advance 



Object 



false 



•KSetOueDateO : DateVatue 
+lsRefundable(} : BoolValue 
<»>SetDueDate() 
+SetRefundable() 
+SetNonrefundableO 
#CreateFofecast() 



<iPerststent» 
Date Amount Interval 



^Starting Date : DateValue 
#Endtng Date : DateVatue 
#Amoun! : MoneyValue 



+GetSt3rt0ate(} : DateValue 
-i-GetEndDate() : DateValue 
•«-GetAmount() : DateValue 
-•-SetStartDateO 
^SetEndDateO 

+SetAmountO 

iK 



Escalation Amounts 



#Due Date : DateVatue 



oPersistentB 
Minimum Guarantee 



-f-GetOueOateO : DateVatue 
+GetTimePeriod() ; Recurring Period 
SetDueDateO 
+SetTimePeriod() 
•*>GetOateAmountlntervatsO : DateAniountlntervalQuery Result 
♦AddDateAnnountlntervalO 
+RemoveDateAmountlnterval(} 

#CreateForecast() 




«Persistent» 
Lump Sum Fee 



#Due Date : date 



+GetDueDate() : os_date 
SetDueDateO 
#CreateForecast() 



ffPersistentn 
Ongoing Fee 



+GetTrmePeriod{) : Recurring Period 
+SelTimePeriod{) 
#CreateForecast() 



«Persistent» 
Other Compensation 



jKDue Date : NullableDateValue 



+GetDueDate() : NullableDateValue 
+SetDueDate() 

#CreateForecast() 



Period 



aPersistentD 
TimePeriod: .'Recurring Period 
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-ogical View 



Contact Package 



€Persrstent» 
Entity::£ntity 


Contact Methods * {ordered} 


«Persistent» 
Contact Method 






#Description : NullableStringValue 


'fGetDescriptionO : NullableStringValue 
•fSetOescriptionO 



'^Database 
Object 



#Area Code : ShortValue 
iH'eleptione Number: ShortValue 
^Extension : NullableShortValue 
#ls Fax : BoolValue = false 



I 



Database 
Object 



Contact Method Type 



« Persistent* 
Telephone 



+GetCountryCode() : ShortValue 
+GetTelephoneNunnber{) : ShortValue 
*GetExtenslon{) : NullableShortValue 
*lsFax() : BoolVahJe 
+SetCountry() 
+SetAreaCode() 
+SetTelephoneNumber() 
+SetExtension() 
SelFaxO 

+SetVoice() 



«Persislent» 
EMail 



#Address : StringValue 
#Domain : StringVatue . 



+GetEmailAddress{) : StringValue 
•f-SetEmailAddressO 



Database 
Object 



1 



Country 



•Persistent* 
Core::Country 



Country 



Databaf 
) Objec 



« Persistent)* 
Address 



#Addfess 1 : StringVatue 
#Addre5& 2 : NullableStringValue 
#Clty : StringValue 
#State or Province : NullableStringValue 
#Postal Code : StringVatue 



+GetMailingLabel() : StringValue 
+GetAddress1() : StringValue 
+GetAddress20 : StringValue 
+GetClty() : StringVatue 
+GetStateOrProvince{) : StringValue 
+GetPostalCode{) ; StringValue 
+GetCountry() : Core::Country 
+SetAddress1() 
+SetAddress2() 
+SetCity{) 

+SetStateOrProvince() 
SetPostalCodeO 
SetCountryQ 



/35 
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Logical View 



Currency Package 



Currtncy Facade 



♦GatCufrendetQ : Iteratof 



«Unit Name : string 
mJnR Symbol : ttring (alternate oid « 1) 



cPersistent* 
Tlme_Period::Open Ended Period 



«Persistenl» 
Currency 



+CunencyO 

^tCountryNameO : string 
^^GetUnttNameO : String 
tGetUnftSymtJoK) : string 
♦ConvertToDoflarO : float 
+GettntefvalsO : Uefator 
«-AddRate[ntervalO 
'^UpdateRatelntenraK) 
RemoveRatelntefvaiO 



''Database 
Object 



1..' Country 



cPerststents 
Core::Country 



Interval (otd) 
l..t 



Conversion Rates 



ftPersistent> 
Currency to Dollar Interval 



#Ootlar Conversion Rate : fkut 
ODe»cription : nullat)le itring 
+GetOoltarRate<) : float 
♦GetCommentO : string 
«ConvenToOoRarsO : float 
♦SetOollarflateO 
+SetComrnent() 



Database 
Object 
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Logical View 

Database Package 

clnterface» 
Database Object 



+lnsert(l : Transaction &) 
+Update{t : Transaction &) 
^•Delete<t : Transaction &) 



GUID 



(Persistent* 
Identity 


GUlO 


DBGUID 


mo ; LongValue 




-GUIDString : string 


+GetID{) : int 
•t-GetGUIDO : DBGUlO 
+NewlDFromDatabase{) 
+operator <0 : booi 
+operalor ==() : bool 




+GUID() 

+GetGuidAsStringO 




* 





spOID 



#Nodes : map<KeyType7\7aIueType> 
#maxLevels : int 
#ma)dJnks ; Int 
#sess[on : m_Session 



-Key Type 



ValueTypei 



Directed Acyclicjs ra p h 



BegInO : Iterator 

End() : Iterator 
#CreateUnks{) : int 
#BuildRootLevel() : int 
#BuildOtherLevel() : int 
#AddChild(} : bool 
#V(sitNode() : bool 
#CreateTableName() : string 
#DropTable() 




« Persistent* 
Security:: User 



User 



+GetSession() : SesstonADO 
+6etUser<) : User 
+Begin() 
+Comnriit() 
^RotlbackO 
DoltQ 




Node 




#Key : Key Type 
#Level : int 

#AdjacentNodes : fnap<KeyType. ValueType> 



+GetKey() : KeyType 
+GietLeveI() : int 

BeginO : Iterator 

EndO : Iterator 

AddChildO 

RemoveChildQ 



(S7 
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Logical View 



Database 
Object 



«Persistenl» 
Securtty::SecurityClas8k- 



Classification 



Object ^ 



aPersistents 
Entlty::Role 



Group 



Roles 

Agreements 



2..* Parties 



a Persistent* 
Entity::Entity 



Documents 



«Pers[stent)> 
Document 



#Verston Number : tong 



+GetSecurityClass() : Security.iSecurityCiass 

+SetSecurflyClass() 

+GetlD() : Int 



^Agreement ID : String Value (alternate old - 1) 
#Name : StringValue 
^Description : NullableStringValue 
^Effective Date : DateValue 
#ExpirattonDate : DateValue 
^Exclusivity : BoolValue - false 
#Assignable : BoofValue = false 
#Revocable : BoolValue - false 
#Transferable : BoolValue = false 
#Confident'al : BoolValue = false 



I 




«Per5istent» 
Agreement 



+GetAgreementlD() : StringValue 
+GetName() : StringValue 
+GetOescription{) : StringValue 
-t-GetEffectiveDateO : DateValue 
+GetExpiratjonDate() : NullableDateVatue 

GetClausesO 
+GetPafties() : PartyQuery Result 
+SetAgreementlD() 
+SetName() 
+SetDescription() 
♦SetDatesO 

SetClausesO 
+AddParty{party : Party&) 
+RernoyeParty() 



1^1 
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Logical View 



Entity Package 



<- — 



Contact Method 





< Persistent* 


•Persistent* 




Security::Entity 


LicenseAgreement::Ucense Agreement 



Database 
Object 



#Name : StringValue 
#Description : NullableStringVatue 



■Persistent* 
Named Entity 



+GetName() : StringValue 
+GetDescripticn() : StringValue 
-*-SetNanie() 
SetDescriptionO 
+GetContactMethods() : ContactQueryResutt 
-AddContactMethodO 
•♦•RenxjveContactMethodO 



Type 



— 1 
__t 



DirectedAcycHcGraph 



Agreements 



Oatabas 
) Object 



•Persistent* 
Rote 



#Name : StringValue 
ipescription : NullableStringValue 



+GetNameO : StringValue 
+GetDescription() : NullabieString Value 
+SetName<) 
SetDescriptionO 



Roles 



Entitv Type 



Database 
Object ^ 



#Star1 Date : DateValue 



Organizations 



•Persistent* 
Organization 



GetStartOateO : DateValue 
+GetLevel() : Organizational Level 
SetStartDateO 
SelLevelO 
-*-GetPeople() : PersonQuery Result 

EndPeople() 
+AddPerson() 
+SetPersonTimePeriod{) 
+RemovePerson{) 
J+GetProducts() : ProductQuery Result 
^ +AddProductO 
-♦•RemoveProductQ 



DirectedAcyclicGraph<Organizatlon> 



Organization 



•Persistent* 
Person 



#Fjrst Name : StringValue 
#Middle Name : NullableStringValue 
#Last Name : StringValue 



Database 
Object 



Organizations 




Level 



•Persistent* 
Organizational Level 



»Levet : StringValue (oid) 
#Description : NullableStringValue 



*OrganizationLevel() 
+GetLevelC) : StringValue 
+GetDescriptionO : StringValue 
SetDescriptionO 



0Name : StringValue 
^Description : NullableStringValue 



« Persistent* 
Organization_People 



+GetPerson{) : Person 
+GetTlmePeriodC) : TimePeriod::Time Perio 
+SetrimePeriod() 



Products 



•Persistent* 
Product 



♦GetNanieO : StringValue 
+GetDescriplion() : StringValue * 
+GetOrgantzationO : Organization 
+SetName() 
^SetDescriptionO 
SetOrganizationO 



Time Period 



•Persistent* 
nmePeriod::Time Period 
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Logical View 



li Document Package 



tPAsset::tP Document 



discos witch/I PTy pe 



«Persjstent» 
Copyright 



♦GetTypeQ : enum IPType 



-'Database 
Object 



#Mark Kind : enumfTrade. Service) 



« Subsystems 
Patent 



« Persistent* 
Trademark 



+GetType() : enum IPType 
+GetClasse5() : Iterator 
+GelMarkKind() : enum{eTrade, eService) 
t-AddClassO 
RemoveClassO 
■♦■SetMarkKfndO 



-^Database 
Object 



Classes 



«Persistent» 
Trademark Class 



#Oisplay Name : string 
^ #Long Display Name : string 
#Description : nullable string 



-KsetOisplayNanDeO : string 
+GetLongDisptayNanr>e() : string 
+GetDescription() : string 



1^0 
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Logical View 



Iterator Package 



r ~ 


1 

PT 1 
t 


, T 

PtrTofteflterAdapt^r 


-ptrtter : auto_ptr< lterator< PT > > 


[ 1 


*GetcountO : int 
4GetNextO:T 
+OetO:T 
4-lsAtEndO : bool 

4<3tttShaUowCopyO : Iterator^ T > * 





1 

Itentor 1 


1 




*G9tCountO ; int 




*<SetNaxtO : TA 








HaAtEndO : tool 








*<SetShatk}wCopyO ■ nerator<T>* 





Shaliowlterator! 



I 

<= I 

I - I 



♦ShaHowtleratofO 
+GetCount() : int 
♦GetNertO : TA 
♦GelO : T& 

-IsAlEndO : boot 

BeginO 

■GetShallowCopyO : lterator<T>' 



-vector : voctof <T> 
Iter : Vector<T>::i(Brator 



Vectortterator 



ShaltowtleratorQ 
♦GetCountO : Int 
^^GetNextO : T& 
♦GetO : T4 
♦IsAtEndO : boor 
■^BeginO 

♦GetShairowCopyO : «efatof<T> 
PushBack(ot)ieci : T) 



-6Ct : set<T> 

Jter: set'0'>::iterator 



♦ShallowlteratorO 
^OetCountO : int 
«GetNextO : T& 
♦GetO:T4 
4-tsAtEndO : bod 
^BeginO 

■^GetShaltowCopyO : lterator<T>< 
i-ln$ert(obiecl : T) 



Vectorlterator 



Setlterator 



IteratorRandomAccessAOapi^.K ' 



•Iter : Iterator < T > 
-Position : fnt 



♦operator QQ : T 



HI 
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Logical View 



Loce^i^se Agireememit Faclf^ge 



Database 
Object ^ 



«Pentstenl» 
Packoge::Asset Pacttag 



Utioenses 



aPersistenU - 
Pockage::Ucen8od_Pactcage 



aPersistenu 
Con::Agrecmont 



Agreement Type 



^Perpetual : BootValue » fatse 

fflnfrfngement Based : BoolValue » fatse 

»Con Sublioenso : BooeVatue «« false 

OAnnuat Audit : BooJVotoe « tiue 

OAudtt At Licensee Expanse : BoofVatue « tme 

OFfivored Nation : BodVaUie » false 

Otmprovefflents : BoolN/otue false 

fFGrant Bade : BoofValiio » fabe 

WWhholdino Percentage : NuHabtePercentValue 




«Perststent» 
Uconso Aorvement 



+<jetQausesO 

. f^GetVUimhotdingPefcenUgeO : NuilablePercentVatue 
+GetP8cfcagesO : PadtageQuenrResuIt 
♦OetCompensationTennsO : TemnQueryResutt 
♦GctStatementsO : SlatementQuoryResuh 
♦OetPaymenUO : PaymeiUQueiyResutt 
«OetExpectedRevenuesO : ExpectedRevenueOuwyResut 
i^SetCtausesQ 

i-SelWithholdingPercentageO 
+AddPaityO 

hRemovePartyO 

>AddCof7ipensationTermO 
4{%erTMveCompertsationTemi(} 
HJpdateCompensatfonTefmO 
♦AddPackageO 

♦RemovePachogeO 



Tenms 



«Persi5tent» 
CQmptnsation::CompensaUon Tarm 



Statefftedts «Persistent» 
. RoyBttyStatemmtriRoyatty Statement 



Infringement 



Payments 



«Persistent> 
Payment: : Payment 



Database 
Object ^ 



Infr Based Agreement 



infringement Reteasa Granted : BoolValue » tnie 
fflnfringement Comment : NuHableStringValue 



^tRelease<) : BoolValue 
+GetCommentO : StringValue 
XSrantReleaseO 

RevoheReleaseO 

S^ommentO 
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Logical View 



License Agreement Transaction Package 



Database:: Transaction 



Find License Agreement 



" +GetUcenses() : LicenseQueryReusIt 
+GetlnfringemenlLtcenses() ; InfringementQueryResult 
+FindLicenses() : UcenseQueryResull 
+Commit() . 



Create License Agreement 



" ffpAgreement : License Agreement * 
+CreateLicenseO 



#PAgreement : InfringementBasedLicenseAgree 

+CreateLtcense() : InfringementBasedLicenseAgreemen 
+Dolt() \ 



Modify License Agreement 




#pAgreement : LicenseAgreement * 




+ModifyUcense() 
+Dolt{) 




Remove License Agreement 




#pAgreemenl : LicenseAgreement * 





+RemoveLicense() 



Create Infringement License Agreement 



•Subsystem* 
License Agreement 



t-DoltO 
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Logical View 



Oiooong Royalty Packcsie 



tfPersistento 
Compensation Term 



ri 



Period 



aPersistenU 
Ongoing Royalty 



•KSetPeriodO : Recurring Period 
SetPeriodQ 



' O Database 

Royalty Type Object 



aPersistentv 
TimePeriod::Recurring Period 



aPersistenta 
Estimated Units 



^Estimated Units : LongVaiue 



•KTetEstimatedUnitsO : LongVatue 
»SetEstimatedUnits() 



* {order id) 



1..1 



^Royalty Unit : StringValue 
#Estimated Unhs Per Period : LongVaiue 



Unit Periods 



aPerslstent* 
Unit Amount Interval 



((Starting Units : LongVaiue {o)d} 
(^Ending Units : LongVatue 
^Amount : MoneyValue 



i-GetStartUnitsO : int 
HBetEndUnitsO : int 
K^etAmountO : float 
fSetStartUnitsO 
i-SetEndUnitsO 
►SetAmountO 



Escalation 



Ampu|it 



aPersistentv 
Royalty Per Unit 



+GetRoyattyUnlt() : StringValue 
GetEstimatedUnitsPerPeriodO : LongVaiue 
GetEstimatedUnitsO : EstimatedUnitQueryResuIt 
AddEstimatedUnitsO 
•t-RenrtoveEstimatedUnitsO 
, J^GetEscalationsO : EscalationQueryResult 
74-AddEscatation() 

RemoveEscalationO 
ffCreateForecastp 



'^Datat>ase 
Object 



Database 
i Object 



aPersistentft 
Sales Amount Interval 



IFStarting Amount : Money Value (old) 
^Ending Amount : MoneyValue 
Royalty Percentage : Perce ntageValue 



>>GetStartingAmount() : MoneyValue 
^GetEnd(ngAmou^t() : MoneyValue 
-GetPercentageO : PercentValue 
•SetStartingAmountO 
-SetEndingAmount(} 
•SetPercentageQ 



^Percentage : PercentValue 

#Net : BoolValue = false 

#Estimated Revenue Per Period : MoneyValue 



'■ , ^ . +GetPercentage() : PercentValue 
Escalation Amounts ^^^^^^^ . g^^^^^^ 



aPersi5tent» 
Estimated Revenue 



^Estimated Revenue : MoneyValue 



-GetEsttmatedRevenueO : MoneyValue 
•SetEstimatedRevenueO 



• {ordere i) 



1„1 



«Persistent» 
Royalty Per Sales Amount 



-GetEstimatedRevenuePerPeriodO ; FloatValue 
+lsPerRoyalty() : BoolValue 
■SetPercentageO 
■SetNetO 
■SetGrossO 

SetEstimatedRevenuePerPeriodO 
+GetEstimatedRevenuePeriods() : Esti mated R even ueQuery Result 
+AddEstimatedRevenueO 
+RemoveEstimatedRevenue() 

'GetEscalationsO : EscalationQueryResult 
+AddEscatation() 

-RemoveEscalationO 

#CreateForecast{) 



Revenue Periods 



aPersistent» 
Royalty Per Royalty Amount 



+lsPBrRoyalty() : BoolValue 
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Logical Vtew 



Patent Package 



•Persistent* 
tPAsseV:!P Document 



Database 
Q Object 



Dtsc,Switch/ 
IPType 



cPersistent» 
PTO Patent 



#Series Code : NullableString Value 

#AppNo : NullableLongValue 

#AppType : NuItableShortValue 

#PubLeveI : NuitableStringVaiue 

#ArtUntt : NullableShoftValue 

#NuinCtaims : NuflableShortValue 

#Exempt3ryf Claim No : NuIlableStringValue 

#Asst Examiner Last Name : NuIlableStringValue 

#Asst Examiner First Name : NuIlableStringValue 

#Primafy Examiner Last Name : NuIlableStringValue 

#Primary Examiner First Name : NuIlableStringValue 

#Num Drawing Pages : NullabieShortValue 

#Num Figures : NullabieShortValue 

^Disclaimer Date : NullableDateValue 

#Num Spec Pages : NullabieShortValue 

#Term Years : NullableFloatValue 

#Reissue Level : NullabieShortValue 

#Retssue App No : NullabteLongVatue 

#Reissue App Date : NullableDateValue 

#Relssue Patent No : NuIlableStringValue 

#Reissue Issue Date : NullableDateValue 

WntlEdition : NuIlableStringValue 



+GetType{) : enum IPType 
•t-GetSeriesCodeO : NuIlableStringValue 
+GetAppticationNumber() : Nullable Long Value 
+GetApplicatlonType() : NullabieShortValue 
+GetPublicationLeve!() : NuIlableStringValue 
+GetArtUnit() : NullabieShortValue 
+GetNumbejOfClaims() : NullabieShortValue 
+GetExempiaryClalmNo() ; NuIlableStringValue 
+GetAsstExaminerLastName() : NuIlableStringValue 
+GetAsstExamlnerFtrstName() : NuIlableStringValue 
+GetPrimaryExaminerLastName() : NuIlableStringValue 
+GetPrimaryExaminerFirstName{) : NuIlableStringValue 
+GetNumberOfDraw(ngPagesO : NullabieShortValue 
+GetNumberOfFtgures() : NullabieShortValue 
■K3et0tsclaimert3ate() : NullableDateValue 
+GetTermYears() : NullableFloatValue 
■KSetReissueLevelO : NullabieShortValue 
+GetReissueApplicationNumber() : NulIableLong Value 
+GetReissueApplicationDate{) : NullableDateValue 
+GetReissuePatentNumber() : NuIlableStringValue 
+GetRefSSuetssueDate() : NullableDateValue 
+GetlntemationalEdition() : NuIlableStringValue 



€ Persistent* 
EPO Patent 



+GetType() : enum IPType 



Object 



Database 
j Object ^ 



« Persistent* 
JPG Patent 



+GetType() : enum IPType 



itabase 
Object 



aPersistent* 
POT 



•♦-GetTypeO : enum IPType 



TODO: Make many of these shorts and strings !^ 
into enumerated data types representing the actual 
kinds of values involved. 



There is a Set function 
for each of these Get functions. 
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Logical View 



PaymmeirDt Package 



«Persistent» 
RoyaltyStalement::Royalty Statement Detail 



«PersistentB 
Compensation:: Expected License Revenue 



Details 



a Persistent]) 
Payment Detail Allocation 



#Amount Allocated : MoneyValue 



+GetAmountAlk>cated{) : MoneyValue 
■♦■SetAmountAIIocaledO , 



«Persistent)» 
License Payment Allocation 



ffAmount Allocated : MoneyValue 



-t-GetAmountAIIocated() : MoneyValue 
SetAmountAllocatedO 



a Persistent D 
EntIty::Bntity 



Payor 
1 



#Amount : MoneyValue 

^Withheld Amount : NultableMoney Value 

#Late Payment Interest Amount : NullableMoneyValue 



Payments 



aPersistent» 
Security::SecurB Object 



* Payments 



Payments 



Expected Reveni> 



« Persistent)) 
Payment 



+GetPayor() : Entity::Entity 
■GetAmountO : MoneyValue 
+GetWithheldAmountO : NullableMoneyValue 
+GetLatePaymentlnterestAmount{) : NullableMoneyValue 
+GetCurrency() : Cun-ency-Cunency 
+SetPayor() 

•i-GetDetailsO : DetailQuery Result 
+AddOetallAllocation() 

RemoveDetatlAllocationO 

-GetRevenues{) : ExepectedRevenueQuery Result 
-(-Add Reven ueAilocationO 
+RemoveRevenueAJIocation() 
♦GetGLEntriesO : GLEntry Query Result 
'AddGLEntr/O 

•RemoveGLEntryQ 



Database 
Object 



Amourtfcurrency 



«Persistent» 
Currency::Currenc 



Entry Type 



aPersislent» 
Debit General Ledger Entry 



»isDebit() : boo! 



aPersistentn 
Credit General Ledger Entry 



HsDebttQ : bool 



Assumption: All the amounts 
are in the same currency 



GL Entries 


2/ 

f 


^Database 
Object 

, — ^ 




« Persistent* 
General Ledger Entry 


« Persistent* 
General Ledger Account 


#Amount : MoneyValue 
#Entry Date : DateValue 


#Account Number : LongValue {oid} 
#Oescriptjon ; NullableString 


+GetAmount() : MoneyValue 
+GetEntryDate() : DateValue 
HsDebitO : boo! 
+S€tAmount{) 
+SetEntryDate() 


Account 


+GeneralLedgerAccount() 
+GetAccountNumber() : LongValue 
-t-GetDescription() : NullableString 
+SetDescription() 
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Logical View 



Ro^lty Statement Paclcaige 



Core::Document O 



#Due Date : DateVatue 
^Receipt Date : DateVatue 
fflnvesfgation Window Date : PateValue 



1 



Database 
Object 



«Persistent» 
Royalty Statement 



■GetUcenseAgreementO 
+GetTimePeriodO : TimePeriod;:Fixedlnterval 
^GetDueDateO : DateValue 
+GetReceiptDate() : DateVatue 
+Gettnvestigatk>n\A/indowDate() : DateValue 

-SetLicenseAgreeinentO 

SetTimePeriodO 
+SetDueDate<) 
+SetReceiptDate() 
+SetinvestigatjonWindowDate() 
•i-GetDetailsO : DetailQueryResult 
4-AddDetail() 

UpdateDetailO 
-t-RemovePetailQ 



License {alternate old = 1} 



{ordered} ' 



•Persistent* 
LlcenseA9reement::LlcenseAgreement 



1./ {ordered) 



#Units Sold ; LongVatue 
^Revenue : Money Value 
#Royalty Due : Money Value 



Statements 



Reporting Period {alternate oid = 1} 



« Persistent* 
TlmePeriod::Flxedlnterval 



Details 



Database 



9 ^^'i^'^ Statement Details 



• Persistent* 
Royalty Statement Detail 



+GettJnit5Sold() : LongValue 
+GetRevenue() : MoneyValue 
+GetRevenueCurrency() : Currency: :Cun-ency 
+GetRoyaItyDue{) 
+GetProduct() : Entity:; Product 
+GetPayments() : PaymentQueryResuIt 
+SetUnitsSold() 
+SetRevenue() 
SetRoyaltyDueO 
+SetProduct() 



Entity:: Product 



Product 



•Persistent* 
Currency ::Currency 



Revenue Currency 



Payments 



{p.Payment;:Payment,Amount = fc;^ 
(SELECT Sum(Amount Allocated) 
FROM Payment Detail Allocation 
WHERE oid = p.oid 

} ______ 



Details 



•Persistent* 
Payment::Payment 



•Persistent* 
Payment::Payment Detail Allocation 
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Logical View 



^ecydlty Package 



Security Focade 



>GotUsefaO * UsefQuefyResutt 
fAddUoerO 
►Remove UsefO 

KSetPofmisakKisO : PermissionOueryResuR 
KSetSecurftyCtossesO : SecuiltyClassQueryResul 
t^AddSecurftyClassO 

►RemowSecurityClaatQ 



sPersistentB 
Security Pormtsston 



gName : StringVstue 



+GetNafneO 
♦GetEntityGUIDO : StrmgValue 



1„1 



tfEntrty QUID : SlringVatue 



+EntltyO 
4Entit/(GU!0 : StringVarue} 
♦GetGUlDQ : StringVolue 



I 



Entity 



cPeralstentA 
Socura Object 



ffCfeation Date : TtmestampValue 
ffModificatran Date : TimestampVafue 
tfVerson Number : LongVelue 
gSecure Object GUID : StringValue 



4-GetGUIOO : StrfngVatue 

■•-IsPemunedCUsef : Enlily. Peimisslon : Security Permission) 
»SetPerTTiissU>n(Usef : Entity, Pem)issioo : Security Permission 



oPenistent* 
User 



ffUser 10 : tdenttty 
0Name : StrtngVahie 
OFufl Name : NullabteStringValue 
^Password : StrfngVatue 
^Version Number : tongVatue 



•K^UserldO : MenUty 
•K3ett4ame<) : StringVabie 
•KyetFuUNameO : StringVatue 
^SetNameO 
-t-SetFuUNameO 
•♦SetPasswordO 
-fCcmfirmPasswordO : boot 
CEncryptO 



Groups 



Secure Obfect Type 



cPerststent* 
User Group 



tfGroup Name : StringVahie 
^Version Number : LongValue 



cPersistentii 
Core::Group 



Classificatjon 



vPersistentv 
Ass«tPackBge::Asset Package 



sPersistent* 
Security Dass 



»Name : StringValue 



<^SecurityClass() 
GetNanwQ : StrtngVahie 



Security Class 



aPersislent* 
Cof«::Oocum ent 



<Perststsnt> 
PaymtnVtPaymani 



This version of IPAM-LS 
does not implement user groups. 



Ml 



wo 00/11575 



A 73 



PCTAJS99/19050 



Logical View 



Time Period Package 



Time Period Visitor 



+VisitFixedlntervalO 
+VisitOpenEndedPeiiodO 
+VisitOtherPeriodO 
*VisitCountUmitedRecuningPeriodO 
+VisitDateUmnedRecumngPeriodO : 



Time Period Facade 



hCreateFixedlntervalO : Fixedlnterval * 
>CfeateOpenEndedPeriod() : Open Ended Period ' 
+CreateOtherPeriodO : Other Period * 

+CreateCountUmitedRecurnngPeriod() : Count Limited Recurring Period 
+CreateDateLimitedRecurringPeriod() : Date Limited Recurring Period * 



Database 
Object ^ 



#StartDate : TimestampValue 



•Persistent* 
Time Period 



+GetStartDate() : TimestampValue 
SetStartDateO 

islnPenod(Date : DateVaiue) : bod 
*l$lnPenod(Date : TimestampValue) : boot 

Time Period Type ^ 



Database 
> Object 



Database 
Ot>jecl ^ 



#End Date : TimestampValue 



«Persistent» 
Fixed interval 



hSetEndDateO 
^GetEndDateO 

K|slnPeriod(Date : TimestampValue) : bool 
^AcoeptO 



«Persistent» 
Open Ended Period 



+lslnPeriod{Date : TimestampValue) : bool 
+Accept() 



Database 
Object ^ 



{StartDate <= EndDate} 




«Persistent» 
Recurring Period 



#Time Unit : enum Timettnit 
#Recurrance Rate : Int = 1 
#Starting Interval : int 
mnlefva! Unit : enum TimeUnit 
ffOescription : NullableStringValue 



+GetPeriodicity() 

-^GeiBndDateO : TimestampValue 
-*-Getlnterval() 

islnPeriod(Date : TimestampValue) : bool 
+SetPerk)dicity() 
+Setlnterval() 

+SetEndDate() 



« Persistent* 
Other Period 



#Descfiption : NullableStringValue 



^AcceptQ 



database 
Object 



€type» 
enum TimeUnit 



Recurring Period Type 



Oatat}ase 
Object ^ 



#End Date : TimestampValue 



«Persistent» 
Date Limited Recurring Period 



lsInPeriod(Date : TilmestampValue) : boot 
+GelEndDate() : TimestampValue 
+SetEndDate() 

McceptQ 



#Number of Recurrences : FloatValue 



aPersistent» 
Count Limited Recurring Period 



+GetRecurrances() : FloatValue 
+SetRecurances() 
+lslnPeriod(Date : TimestampValue) : bool 
-^AcceptQ 



^ Database 
Object 
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^gical View 



Value Package 



#vValue : _variant_t 
#old^vValue : _variant_t 
»reptaoed_vValue : _variant_t 
Unliable Tbool 



ValueHolder 



•t^GetValueO : _varianM 
-t-lsChangedO : bool 

lsChanged(value : VatueHotder) : bool 
+lsNultO : bool 

NulUfyO 
+SefValue() 
♦RestoreO 
i-Roliback() 

■lOSDateTimeToVarianfnmeO 



WariantTimeToOSDateTimeO 



ValDS-- 



I 

nultable : booli 

t 



+GetValue() : T 
+SetValue() 



DateValue 



+GetVatue{) : os_dale 
+isNul)() : boot 
+NuHify() 
-^SetVal^e() 



TimestampValue 
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